Intel nejspíš čekají problémy – bezpečnostní chyba v procesorech? |
autor: Pavel Boček , publikováno 4.1.2018 |
Dle dostupných zpráv, které se začaly rojit na Nový rok, možná čeká společnost Intel jeden z nejhorších průšvihů v historii. Postiženy mají být ale i procesory dalších výrobců.
V posledních letech se nejedná o jediný větší aféru, můžeme připomenout TSX bug v roce 2014 (Haswell/Broadwell), potíže s procesory Atom řady C2000 a možná i jiných (který stále dopadá na uživatele síťových úložišť, miniserverů, síťových prvků apod.). Další je poslední měsíce rozmazávaná platforma IME (Intel Management Engine), což je věc, která se zatím příliš nikam nehla, přitom je to potenciálně otevřená díra do spousty zejména pracovních počítačů, jelikož v nich běží a zpravidla se ani nedá prokazatelně vypnout. Nynější problém ale svým rozsahem může být ještě o řád horší, protože je zneužitelný mnohem snáze a bez jakéhokoli fyzického přístupu k počítači (s IME byly zatím předvedeny pouze útoky s přístupem k zařízení).
Co se na nás řítí?
Pokud to krátce shrneme, před pár měsíci se objevily nové možnosti útoků přes virtuální paměť s cílem převzetí kontroly nad počítačem z uživatelského prostředí, a to dokonce i uživatelskými interpretovanými skripty (např. Javascript), nikoli pouze přímo spustitelnými programy (binárky). S ohledem na to, že skripty jsou dnešní weby naprosto přecpané a jejich potenciál si nyní uvědomují i provozovatelé botnetů např. pro těžbu kryptoměn (typu CryptoNight a podobných), snad každému je zřejmý potenciál tohoto průšvihu (zasloužilo by si to už i jiné označení).
Potenciálně je možné nejen propašovat do paměti binární kód a převzít kontrolu nad HW, ale i (jen) číst obsah vyhrazené paměti jádra systému a tak se dostat např. k HW/SW klíčům, heslům a vlastně takřka jakýmkoli datům v paměti. Poměrně záhy začaly v historii téměř nevídaným tempem vznikat téměř anonymní a nedokumentované opravy v samotném core linuxového kernelu, které nyní začínají být nasazované. Současně i Microsoft začal urychleně pracovat na aktualizacích pro jádro jejich operačních systémů, které mají přijít příští úterý. Z prvotních testů, které jsou nyní k dispozici, vyplývá, že řešení na úrovni operačního systému může mít za následek zpomalení někde mezi 0 a 75 % s tím, že nejvíce asi problém dopadne na velké providery cloudových a virtuálních služeb, kteří mohou čelit propadu výkonu mezi 5 a 30 %.
Podle vyjádření Toma Lendackyho z AMD se problém netýká procesorů společnosti Advanced Micro Devices. Intel nechtěl zveřejnit podrobnější informace, dokud nebude k dispozici řešení, v reakci na množící se články ale včera přišel s předběžným vyjádřením, ve kterém se ostře ohradil proti tomu, že by byly problémem stiženy pouze procesory Intel, ale má se týkat i mnoha dalších výrobců čipů a řady operačních systémů. Intel ve svém vyjádření nepopírá, že budou mít opravy za následek pokles výkonu, ale míra zpomalení má být závislá na typu zátěže a časem by se měla snížit. Domácí uživatelé počítačů by pak podle Intelu neměli pocítit významný dopad na výkon.
Virtuální paměť, chráněný a uživatelský režim
Pro ty, kdo se – stejně jako já – v této oblasti nepohybují a tak o tom mají informace jen velice povrchní (nebo to už dávno zapomněli), se pojďme ve stručnosti podívat, o čem se bavíme. Programy v moderních operačních systémech nepracují přímo s fyzickou pamětí, ale pracují s mezivrstvou spravovanou operačním systémem, virtuální pamětí. Ta je u všech významnějších systémů rozdělená do segmentů (stránek). Operační systém přiděluje stránky, vede si stránkovací tabulku (aby věděl, co je kam přiřazeno) a následně teprve umisťuje data z virtuální do fyzické paměti (zpravidla operační paměť RAM, různé vyrovnávací paměti v procesorech, ale i stránky na pevném disku). Program dostane vyhrazenou jistou spojitou část a o přiřazení reálné fyzické paměti se pak stará operační systém, přičemž překlad zajišťuje k tomu určená jednotka uvnitř mikroprocesorů. Systém podle svého uvážení s fyzickým umístěním dat různě šachuje dle potřeby (umístění v RAM či na sekundární úložiště jako stránkování, také nazýváno swap). Je poměrně zásadní vlastností, že různé programy mají každý svou vlastní virtuální oblast a nesmí sahat, ba ani vidět do virtuálního prostoru těch ostatních. Všechny běžné programy běží v tzv. uživatelském režimu.
Operační systém, resp. jeho jádro, běží v úplně odlišném, privilegovaném režimu jádra. Má také svůj vlastní virtuální adresní prostor. Tam běží i mnoho ovladačů, z čehož právě tak často vyplývají problémy s nestabilitou (špatně napsaný ovladač, případně HW problém, může vést k tomu, že jeden proces, např. ovladač, zapíše něco někam, kam nemá, což pak vede k pádu jádra a tím celého systému). Režim jádra dává všemu v něm provozovaném mnohem bližší přístup k HW, moderní procesory mají přitom přímo implementované mechanismy pro oddělené spouštění instrukcí v režimu jádra a v uživatelském režimu. Kdykoli nějaká aplikace potřebuje někam přistoupit (číst, zapsat), dojde k tzv. přerušení, kernel vykoná pár cyklů, provede HW operaci a vrátí prostředky programu. Výrobci mikroprocesorů x86 (tedy Intel, AMD a VIA) samozřejmě jdou uživatelům naproti a implementují mnoho mechanismů, jak nejrůznější procesy zrychlit a namísto SW řešením to řešit na úrovni mikroprocesoru složitějšími instrukcemi (tedy obvykle rychleji, s využitím méně instrukčních cyklů) přesně v souladu se zaměřením architektury (CISC). S rozmachem virtualizace před zhruba dekádou právě došlo současně s uvedením nové architektury procesorů Core, Nehalem, k nasazení výrazně vylepšené podpory virtualizace, a to i právě v oblasti práce s virtuální pamětí. Mnoho těchto mechanismů zůstává aktuálních doteď.
(K)ASLR
V Linuxovém jádře se za poslední zhruba rok událo poměrně mnoho změn, které téměř zcela překopávají systém práce s pamětí. Jednou z nich je koncept ASRL, Address Space Layout Randomization (randomizace rozložení adresního prostoru). Mj. díky práci rakouské Graz University of Technology byly odhaleny způsoby, jak se dostat k informacím o fyzickém rozmístění dat v paměti u dřívějších verzí systémů, kde jádra typicky uchovávala části dat ve stále stejných oblastech. Ty se daly díky chybám v jaderných aplikacích jistými způsoby práce s pamětí odhalit, nepovoleně rozšířit adresní prostor aplikace (aplikací) v uživatelském režimu a z oblastí programů v chráněném režimu pak číst, nebo do nich i zapisovat. Byla tak implementována metoda randomizace, která chráněné aplikace laicky řečeno „rozháže“ při každém spuštění na jiné místo, aby tak byla podstatně ztížena jakákoli možnost škodlivého kód zjistit, kde má jádro svá citlivá data umístěna. Není to přímo řešení, ale fakticky učiní pravděpodobnost úspěchu útoku předchozím způsobem blízkým nule. Jaderný ASLR (kernel ASLR či KASLR) tak má za cíl rozházet data jádra a jejich umístění před programy v uživatelské oblasti bedlivě tajit. V tomto však SW výrazně spoléhá na to, že HW, tedy zejména mikroprocesor, zajistí důkladné oddělení instrukcí v režimu jádra a instrukcí v programovém režimu.
Záhy však byly teoreticky popsány způsoby, jak KASRL úplně obejít právě zacílením útoku na HW, tedy mikroprocesor. Mezi jinými zejména útokem na TLB (transaction lookaside buffer), což je malá interní cache právě v jednotce pro zpracování paměti v procesorech (typicky mezi každou úrovní paměti), kam si jednotka ukládá poslední pozice překladů virtuálních adres na fyzické, aby si ušetřila čas při dalším volání. Někdo si možná vybaví aféru kolem TLB chyby u procesorů AMD Phenom, při které ve specifických případech mohlo dojít k poškození dat přesouvaných mezi cache procesorů (data byla v několika cache současně a mohlo dojít k jejich změnám na jednom místě a následně ke kolizi). ASLR a KASLR přímé metody řetězením škodlivého kódu do fragmentů (např. s využitím return-oriented programming/ROP) v podstatě znemožňují, neboť náhodné využívání paměti již aplikacím znemožňuje se dostat k informacím o tom, co kde v paměti je. Dá se však k nim dostat přes „postranní kanály“, například právě snahou dostat se do TLB. Dále jsou indicie, že problémy s TSX u některých procesorů v roce 2014 mohly vést právě i k úniku takových dat. Konkrétní už dříve využívaný způsob spočíval v tom, že aplikace záměrně vyvolala chybu typu page fault (přístup do paměti, která není adresovaná pro tuto aplikaci) a měřila si čas zpracování této chyby. Pokud tam nějaká data byla, opakování trvalo kratší dobu a kód tak mohl postupně zjistit, že v dané oblasti skutečně „něco je“, a to dál zneužít. Instrukce TSX toto řešila mnohem rychleji uvnitř procesoru, bez operačního systému, kód se tak dozvěděl stejnou věc mnohem rychleji a spolehlivěji. To Intel vyřešil vydáním mikrokódu, který TSX zcela vypnul.
Další metody se zaměřily na využití chyb v predikčních funkcích procesorů, které jsou jedním ze způsobů, jak výrazně mezigeneračně zvyšovat výkon. (Princip je takový, že procesor analýzou kódu odhaduje, jaké instrukce mohou být potřeba příště, a sám je už předem nahrává do paměti.) Tak se dala zjistit nejen platnost programu nedostupné virtuální adresy, ale i její velikost. V Linuxu mohl útočník dokonce SW prefetchingem zjistit i přesnou fyzickou adresu pro něj nepřístupné části virtuálního adresního prostoru.
Podezření na problém
Zcela dle doporučení Intelu při vývoji moderních OS došlo k tomu, že pro zrychlení operací systémy alokují části jádra přímo do oblastí aplikací v uživatelském režimu. Když pak program zavolá jádro přerušením, tak je načtení modulu a vykonání operací jádra rychlejší. Zabránění přístupu k těmto sekcím je zařízeno nižšími právy uživatelské aplikace uloženými v tabulce v procesoru. K tomu se právě dá postupy popsanými výše za jistých okolností dostat, nebo to obejít a přístup umožnit i neprivilegované aplikaci. Jedním z řešení by bylo striktně oddělovat oblasti uživatelské a jaderné paměti, což si ale vyžaduje poměrně značné přepsání konceptu jádra a navíc to má zásadní vliv na výkon, kdy je nutné často zcela vyprazdňovat cache procesorů a data tak načítat stále z operační paměti. To jde přesně proti konceptu dnešních procesorů a systémů, kdy je snaha naopak zbytečně velká kvanta dat nepřesouvat sem a tam. Rakouský tým sice přišel s návrhem konceptu KAISER (Kernel Adress Isolation) kterak za pomoci zcela nového šedého adresního prostoru problém vyřešit za údajně téměř nezaznamenatelného propadu výkonu (viz materiál KAISR), otázkou ale je, jak se k tomu pak při implementaci postavit.
Dle dění v posledních pár dnech je ovšem zřejmé, že problém je asi výrazně závažnější, než si kdokoli myslel, neboť popisované změny byly v pouhých několika posledních měsících, možná týdnech, implementovány přímo do linuxového jádra, kde se nyní objevují. Co je asi ještě horší je fakt, že dokumentace zcela chybí a popisy v kódu jsou zmatené. To vše naznačuje, že problém je dost závažný, a tak je záměrně udržováno embargo. Očekává se, že podrobnosti budou odhaleny příští úterý s tím, jak vyjdou kritické aktualizace operačních systémů Windows. Systém MacOS od verze 10.3.2 již údajně záplatu obsahuje. Mezitím několik největších poskytovatelů cloudových služeb ohlásilo na 10. ledna výpadek služeb s tím, jak budou instalovat aktualizace od Microsoftu. Utajená aktualizace připravená k vydání je už údajně připravena i u managera Xen. Jakýchkoli poskytovatelů virtuálních služeb se totiž problém dotýká také velice citelně – jak již bylo naznačeno, možnost dostat se do chráněné oblasti paměti znamená, že se může škodlivý kód na virtuálním stroji dostat dokonce i k datům na ostatních VM na tom samém fyzickém stroji. U hypervisoru Xen už údajně dokonce docházelo koncem roku k opakovaným kolům útoků. Že je to hrozba reálná a bug existuje, dokládá i důkaz, který připravil během psaní tohoto článku doktorand na univerzitě Vrije v Amsterdamu.
Z vyjádření vývojáře AMD Toma Lendackyho o tom, že procesory AMD nejsou zasaženy, neboť podobné funkce vůbec nevyužívají, se dá dovodit, že problém by se mohl týkat právě prediktoru v procesorech Intel (a dalších). V rovině spekulací se hovoří o tom, že procesory mohou za určitých okolností vykonat instrukce bez toho, aby si ověřily jejich oprávnění, a tím tak zcela obejít dosavadní opatření ze strany OS k tomu, aby se škodlivý kód nedostal do chráněné oblasti. Teoreticky jde problém řešit třemi způsoby: na úrovni mikrokódu, na úrovni operačního systému, nebo přepnutím procesoru na in-order zpracování instrukcí (což nám výkon vrátí někam k architektuře Atom starší než Silvermont, vycházející z Intel P5 – původní procesory Pentium a Pentium MMX). Spekuluje se, že chyba je tak závažná, že na úrovni mikrokódu rozumně opravit nepůjde, ostatně by tak již Intel nejspíš učinil. In-order také nikdo nechce. Proto bude nejspíše řešena na úrovni OS. Ačkoli to, že časem na úrovni mikrokódu vyřešena bude, je stále ve hře, neboť je možné záplatu (nejen kvůli procesorům AMD) i v Linuxu parametrem vypnout, případně také vůbec neaktualizovat (i když aktualizovat BIOS serveru je snad ještě horší a nedělá to skoro nikdo, když i dnes to nezřídka znamená, že bude do serveru zanesen ještě další problém, který tam před tím nebyl).
Nynější situace je taková, že jako nebezpečné jsou u linuxových patchů označeny všechny procesory Intel, jak informuje server Phoronix. Minimálně momentálně s touto poměrně horkou jehlou šitou záplatou tak bude platit, i přes výše zmiňovanou studii o KAISR, poměrně výrazný výkonnostní propad, který dle počátečních testů v některých aplikacích je zmiňovaných 5–30 %, ve specifických případech ale i výrazně více. Můžeme zatím pouze spekulovat, zda to je tím, že se koncept KAISR neukázal být vhodný, nepodařilo se jej tímto způsobem implementovat (nebo to přijde později), anebo je problém v procesorech tak závažný, že ani KAISR nepomáhá. Podrobnosti se dozvíme pravděpodobně až příští týden. Je pravděpodobné, že některé novější procesory budou časem označeny jako bezpečné. Rovněž ty z posledních generací, které mají instrukci PCID (Process-Context Identifiers) by měly být propadem výkonu zasaženy výrazně méně.
Jak již tedy bylo řečeno, v AMD si nemohli přát lepší začátek roku. Stihli již připravit patch, který nové záplaty u procesorů AMD neaktivuje, těch pár enterprise uživatelů procesorů Bulldozer navíc nyní dostane rovněž pěkný dárek, když všechny konkurenční servery postihne rána, která jejich výkon srazí. I přes zprávy o chystané těžké konkurenci se Ryzeny prodávají jako na běžícím páse (v popisovaném nasazení – stejně jako Bulldozery ve srovnání s Core té doby – překonávají i nynější procesory Intel velice výrazně), EPYC nyní dostane obrovský boost. Kdo chce dobře investovat, měl by rychle uvažovat o nákupu akcií AMD. Jen za včerejšek již zaznamenaly nárůst o 9 %, a to se informace teprve pomalu dostávají na světlo, zatímco Intel se zatím nejníže propadl o 7 % (a pak částečně vyrostl zpět).
Zdroj: python sweetness, The Register
Redakce si vyhrazuje právo odstranit neslušné a nevhodné příspěvky. Případné vyhrady na diskuze(zavináč)pctuning.cz
Další články v kategorii
- MSI představilo nové notebooky s výkonnými grafikami GeForce RTX 30
- Uvede Honor zítra první telefon se službami Googlu?
- Philips 288E2UAE je nový monitor se 4K rozlišením
- Stahujte zdarma Star Wars Battlefront II. Máte na to ale už jen pár hodin
- ADATA připravuje karty SD Express, nabídnou rychlosti jako externí SSD
TSX bug s tím nijak nesouvisí.
https://www.pcworld.com/article/3245508/components-processors/intel-responds-to-the-cpu-kernel-bug.html
During a conference call Wednesday afternoon, Intel shed more light on the CPU kernel vulnerability, now being referred to as a “side channel analysis exploit.” Expect to see patches roll out to address the flaw over the next several weeks, Intel executives said. The performance impact of the patches is expected to be at frustrating levels—somewhere between 0 and 30 percent, though “average” PC users are expected to see little impact.
...
The flaw was first discovered by Google’s Project Zero security team, says Intel, which Google confirmed.
...
The companies had planned to make the disclosure next week when the patches became available.
https://googleprojectzero.blogspot.cz/2018/01/reading-privileged-memory-with-side.html
....
“We’re aware of this industry-wide issue and have been working closely with chip manufacturers to develop and test mitigations to protect our customers,” a Microsoft spokesperson said in an email. “We are in the process of deploying mitigations to cloud services and have also released security updates to protect Windows customers against vulnerabilities affecting supported hardware chips from Intel, ARM, and AMD.”
Problém "Meltdown", proti kterému je aplikován KAISER patch, a který je reálně exploitovatelný, je pak vlastní pouze Intelovským CPU, která nejsou in-order (tj. vše s výjimkou starých Atomů)
Ale zas pokud je to i problém starých CPU, tak PoS 2009 by měl update dostat
V jeho pripade se jedna o radove miliony dolaru.
Vy by jste to neudelal?
ps: a by to bylo zneuziti informaci, tak by jste mu musel dokazat umysl. Jak toto dokazete, opravdu nevim.
Takze no tak.. ;)
Podle dalších informací to vypadá, že patch v Linuxu je zatím taková rychlovka, která prostě v základu u všech procesorů x86 přechází na hrubě oddělené prostory jádra a aplikací, což s sebou nese i mnohem častější vyprazdňování cache (flush). AMD na to reaguje vydáním hotfixu, kterej to vypíná při detekci procesoru AMD.
Co je SKUTEČNĚ problémem se zcela jistě zatím neví - nebo aspoň sem to nenašel včera - uvidíme až se vydaj dokumentace. Pak začnou vycházet skutečný záplaty, nebo aspoň jejich selektivní aplikace na skutečně zranitelný procesory.
Je pravda, že zmíněná záplata hrubě oddělující adresní prostory skutečně paušálně zvyšuje bezpečnost všude. Na druhé straně se ale tvrdí, v rozporu s PR zprávou Intelu, že ARM a AMD to nepotřebuje. ARM64 má navíc dva bity v registrech, který specifikují práva procesů a tak se nemůže nikdy stát, že to spustí něco uživatelskýho v privilegovaným (vyšším) režimu, protože to vždycky ví, co odkud pochází. U AMD vlastně možná podobně, protože snad nikdy nepustí nic z nižšího ringu do prostoru paměti vyššího ringu bez jasnýho přiřazení.
Jsme zvědavý, kdy se jim podaří snížit tu šílenou degradaci výkonu a o kolik, zda se to vůbec někdy vrátí na původní stav.
..dnes je to Intel, zítra Nvidia, pozítří AMD a poškozené budou pokaždé miliony zákazníků.
Teď mě tu asi zavalí palce dolů od všech majitelů Ryzenu, ale než se tak stane, je třeba si položit otázku. Jak velké bezpečnostní riziko hrozí běžnému uživateli/spotřebiteli? Jak velký propad výkonu lze u spotřebitelského HW čekat? Všem je jasné, že případné zneužití bezpečnostní díry bude mít spíš dopad na podniky, vládní organizace apod. Neumím si představit, že by počítač běžného uživatele byl tak lákavý, že by někdo ztrácel čas zneužitím CPU na takové úrovni, o které se může běžnému uživateli jen zdát.
Zároveň se ale už nikdo tak moc nepozastavuje nad zneužíváním strojového času běžných uživatelů, kteří ani mnohdy neví, že jejich stroj těží kryptoměnu pro někoho na druhé straně planety. Žijí ve své bublině nevědomosti, stahují vše čistě pro vlastní potřebu, takže nikomu neubližují a je jim to jedno. Pak přijde článek jako je tento, kdy ještě ani sám Intel pořádně neví co a jak bude řešit, ale oni už jsou rozhodnutí, další CPU bude AMD. Do toho přijdou odborníci z PC tuningu, kteří vždycky věděli, že je s Intelem něco špatně, všem to říkali a tak dále.
Situace by byla jiná, kdyby tady opravdu byl zaměstnanec Intelu z R&D a mohl se ke všemu vyjádřit. Což se ale nestane. Takže dokud nedojde na lámání chleba, je třeba být klidný s výroky.
https://mobile.twitter.com/misc0110/status/948706387491786752
nuda nie?
Nevymyslel USB někdo z Intelu? Možná IBM? Už nevím. Od těch dvou firem už nikdy nic nechci.
len otacas, hore si sa pytal, ake velke bezpecnostne riziko to je. ja vravim ze velke, a doplnam linkom, preco. A ty to bagatelizujes, lebo Intel svaty a jediny.
Ryzeny ako take neoptimalizovane boli len nevyuzivani lepsich ram. trvalo to 3 mesiace, kym sa to dalo dokopy. Ako to suvisi s bezpecnostnymi dierami Intel procesorov?
Jinak, krádeže informací z velkých IT firem se dělají vcelku jednodušším způsobem. To máš takhle zaměstnance s vyšším oprávněním uvnitř firmy, který má firemní notebook. No, a co se nestane, notebook se ''ztratí''.
mozno sa da napalit na nejake zariadenie jeho ine ID, ale potom OS ma problem pridelit mu spravny driver nie?
Pokud HW v tak ohromným množství bezpečnej není, tak je to obrovskej průser, a zneužitelnost je ohromná. Od čtení věcí, kam to nemá mít přístup (jako že systémových věcí) po samozřejmě získání výlučnýho přístupu k HW, spuštěním klidně strojovýho kódu, a následné totální obejití OS a převzetí kontroly nad počítačem. Demonstrovány byly tyhle útoky i přes JS, jak jsem psal. A ten je úplně všude. To vám nepřijde jako problém?
Jinak naopak u běžných firem a úřadů co mají vlastní stroje, kde uživatel nic nespouští, to problém ani není. Problém to je u hostingů a providerů, kteří pronajímají v podstatě výpočetní výkon, kde si pak může útočník resp. škodlivej kód něco pustit v jedné VM a získat přístup na všechno.
Jenom u oken se to řešilo často prostě fixem přes BIOS že když záznam není v TLB, tak se řadič nesměl podívat do cache, ale přímo do RAM. Ale stačilo to taky vůbec neřešit pže pravděpodobnost, že se to stane na desktopu při běžným použití, byla téměř nulová.
Pokud o tom víte víc, tak se můžete podělit…stejně jako dál blábolit, jistě
Tak uvidíme, čo to spraví z reálnym výkonom, obzvlášť herným keďže posledné roky vlastne od Sandy i5/i7 sú Intely parádne herné CPU...
Každopádne, asi poriadny prúser
pro hry je to spis pozitivni, ale provozovatele datacenter asi strihaji pulkama osmicku drat....
Ale v tuto chvili tezko hadat, jaky to bude mit dopad. Zatim je vec krajne nejista, viz posledni tiskove prohlaseni Intelu. To je fakt zajimavost.
- propady jsou meřitelné i v desítkách procent takže jestli nepřijde nějaká zázračná revize současných oprav v OS či IME tak je věc docela jistá teď už jen změřit kde jsou největší ztráty a kde naopak minimální (v herní oblasti jsou rozdíly max pár % takže naprosto zanedbatelné v rámci chyby měření)
ohledně 970 ten dopad byl .. před nahozením opravy kdy se odstavila pomalejší paměť na vedlejší kolej se to projevovalo a i po aplikaci opravy při potřebě více jak 3,5GB VRAM se to projevilo ... jen díky tomu že to byla mírně ořezaná GTX 980 s dostatečnou rezervou výkonu to uživatel skoro nepoznal(spíš neměl s čím porovnat aby poznal rozdíl) navíc málo titulů si sáhlo na víc jak 3,5 GB s takovým nastavením aby 970 podávala slušné fps nic to nemění na tom že NV lže o svém produktu
1) Nejedná se o "pravý" bug, aplikace nemůže běžným postupem číst data na která nemá nárok.
2) Data unikají prostřednictvím postranního kanálu pomocí informace cache-hit / cache-miss.
3) Bug spočívá v objevení postupu, jak procesor donutit pokusit se načíst paměť na kterou aplikace nemá přímo povolení, pomocí spekulativního čtení a následně výsledek čtení odeslat postranním kanálem.
4) Postranní kanál spočívá v sadě cache lines, kde index cache line s cache-hit představuje výsledek operace, ostatní cache line mají cache-miss.
AMD se mimochodem podle jejich vyjádření netýká ani jeden ze tří způsobů, jak se k tomu dostat, kvůli odlišné implementaci.
AMD se netýká pouze meltdown.
Spectre se týká Intelu, AMD i ARMu a patrně všech dalších se spekulativním vykonáváním kódu.
Meltdown dira v Intelu je. Jestli je to opravdu chyba v jejich implementaci nebo chyba navrhu jejich implementace, je nepodstatne.
Ve firemnim sektoru si myslim bude obcas nekdo pekne na*raty ;)
A samozřejmě, že to teoreticky funguje na Sandy Bridge, na těch jsou všechny varianty Spectre a navíc mnohem pálivější Meltdown, ne?
Plácání je leda tak vaše omlouvání Intelu relativizací slova "pravý" nebo "bug" v bodě 1) a míchání S Spectre s nesouvisejícím popisem Meltdown v bodě 3), jak se ostatně může každý přesvědčit na https://meltdownattack.com/ . Takže děkuji za plácavé vysvětlení, ale ne děkuji
To je asi tak na úrovni napsání "Hello world!" a tvrzení "mám webovou stránku". Prakticky využít Spectre (zvlášť tu variantu, která částečně platí i na procesory AMD) je v reálném světě trochu jiné kafe.
AMD se to údajně netýká proto, že u nich je délka cyklu stejná nezávisle na tom, jestli data byla správná, nebo ne. Myslim že todle je možná důvod, proč měl Intel o něco vyšší IPC (sem tam se něco vykonávalo rychlej)…a teď o to přijdou
So Much FUD
Intel CEO Brian Krzanich also recently sold $11 million in stock, which some have proclaimed is a sign that he's unloading his shares before a pending disaster. However, Krzanich sold the stock under a 10b-51 plan, which is a pre-planned sale of stocks intended to prevent insider trading. The nature of Krzanich's transactions makes it unlikely that the trades are a precursor of a major monetary loss for the company.