Opět chyby v CPU Intel: díry, ale i nestabilita. Opravy zhorší výkon všech Skylake

Intel 12. listopadu publikoval 77 zranitelností, z nichž některé jsou přímo v křemíku procesorů. Potřebují aktualizaci mikrokódu, která bohužel sníží výkon.

15

Brzy tomu budou dva roky, co se provalily bezpečnostní problémy či díry v procesorech nazvané MeltdownSpectre, po čemž následovala řada objevů podobných problémů, kdy typicky spekulativní vykonávání instrukcí v procesoru může side channel útokem vést vyzrazení dat, s kterými CPU pracuje – bežící proces, včetně třeba javascriptu na webové stránce nebo klienta cloudového serveru, tak teoreticky může ukrást citlivá data z PC/serveru. Spectre a další chyby úplně změnily do té doby jednoduchou situaci v procesorech (na které se do té doby dalo pohlížet názorem, že „just works“) a bohužel také platí, že ač už jsou to od té doby skoro dva roky, další bezpečnostní problémy se objevují neustále. Minulý týden jich bylo odhaleno dokonce několik postihujících Intel. Částečně jsou to kuriózně dokonce ne problémy jen bezpečnostní, ale i bugy, které mají za výsledek „jenom“ nestabilitu. To je překvapivé, protože to postihuje jádra Skylake, která po několika letech na trhu sotva lze považovat za čerstvý nevyzkoušený hardware.

Intel publikoval minulý týden dokonce několik (celkem 77) různých bezpečnostních chyb/CVE, nicméně drtivá většina se týká firmwarů a hlavně ovladačů, u kterých jde o relativně rutinní situaci, kterou vyřeší aktualizace, které (jak určitě víte) je dobré vždy u důležitých součástí systému aplikovat. Nicméně mezi problémy jsou opět i další chyby v CPU Intelu, které v minulosti odhalili bezpečnostní výzkumníci a dosud byly pod NDA.

1. TSX Asynchronous Abort: MDS zranitelnosti se vrací i tam, kde už měly být opravené

První bezpečnostní problém je označený jako „TSX Asynchronous Abort“ (CVE-2019-11135) neboli TAA podle operace, v které se slabé místo nachází. Jak už jméno značí, týká se procesorů Intel s podporou instrukcí pro transakční paměť TSX. Ne všech, protože TSX je u řady modelů vypnuté, a kromě toho také zneužití typicky obnáší využití Hyper Threadingu, který má řada procesorů zablokovaný. AMD ani Zhaoxin/VIA nemají rozšíření TSX, takže jejich CPU se ani teoreticky nemůže tato zranitelnost týkat.

Intel Xeon Cascade Lake oficialni Platinum 9200 8200
Vlevo: Intel Xeon Cascade Lake AP s dvěma čipy a až 56 jádry; vpravo: klasický Xeon Platinum 8200 pro socketLGA 3647

Zranitelnost TAA je poddruh MDS zranitelností (také známých jako ZombieLoad), ovšem NDA na tuto variantu bylo prodlouženo, takže je zveřejněná až nyní. Napadá i nejnovější procesory Core 8. a 9. generace (mělo by jít konkrétně o čipy Whiskey Lake a Coffee Lake Refresh) a současné Xeony Cascade Lake-SP (a s nimi asi i highendová desktopová Core i9-10000X), které by podle Intelu snad měly být proti předtím zveřejněným formám MDS útoků odolné.

Chyba používá nedostatek v implementaci TSX, kdy zrušení operace (TSX Asynchronous Abort) dovoluje programu bežícím na jednom vláknu jádra s HT zjistit obsah paměti, s kterou pracuje jiný proces na druhém vláknu. Jde o side-chanell timing útok, kdy útočník sleduje dobu provádění zrušení operace TSX a porovnání těchto časů dovoluje odvodit obsah paměti. Důvod je totiž, že během provádění onoho zrušení proces může získat přechodně přístup k datům, ke kterým neměl, není zde pohlídána integrita. Na serveru tedy může jeden uživatel šmírovat jiné, dopady jsou v podstatě stejné jako u Spectre a podobných děr.

mds zranitelnosti utok zombieloadJiž předchozí softwarové ochrany proti MDS například v Linuxu by měly proti této chybě pomáhat, ale v současnosti operační systémy neví o tom, že je mají na tento nejnovější křemík aplikovat, protože doposud nové revize považovaly za bezpečné. Aby byly opravy aplikovány, bude potřeba jádro operačního systému aktualizovat. Do té doby je možné vypnout podporu TSX, což zamezí zneužití díry TAA. Po aktualizování operačního systému a tím aktivaci ochran proti MDS zranitelnostem/TAA ovšem uživatelé budou mít určitý výkonnostní postih kvůli těmto ochranám. Podle testu webu Phoronix, který zkoušel benchmarkovat různé Linuxové aplikace/benchmarky na Xeonu Cascade Lake, to může být až 8% pokles (geometrický průměr). V některých případech může být lepší vypnout TSX a díky tomu běžet bez ochran.

Intel zároveň vydává aktualizovaný mikrokód, který na Cascade Lake a dalších nových revizích procesorů přidá ochrany proti tomuto podtypu MDS zranitelnosti. Není jasné, zda tato aktualizace pouze zajišťuje, aby CPU nově hlásila, že je zranitelné na MDS zranitelnosti (to dosud nedělala), a tím se na nich automaticky použily již předchozí opravy v operačních systémech, nebo zda bude přítomná i nějaká další ochrana.

Galerie: Bezpečnostní chyby MDS v procesorech Intel: ZombieLoad, Fallout, RIDL (odhalení květen 2019)


Podrobnosti k chybě TSX Asynchronous Abort

2. iTLB multihit: zaseknutí PC či DOS útok

Bohužel to není jediná hardwarová chyba. Další dvě jsou zajímavé tím, že jejich zneužití může vést k nestabilitě či pádu systému, což na serveru ovšem také je bezpečnostní riziko (umožňuje DOS útok odstavující server). Na tyto chyby procesorů jsme byli před Spectre a přívalem chyb umožňujících nepozorovaný únik dat zvyklí jako na hlavní typ „bugů“ či „errata“ v procesorech, nyní to ovšem působí skoro jako závan čerstvého vzduchu, pokud si z toho smíme trošku udělat legraci.

Chyba iTLB multihit (CVE-2018-12207) je opět chyba mikroarchitektur procesorů Intel (u konkurenčních CPU by se tedy neměla vyskytovat, jde o implementační detail, ne o vlastnost instrukční sady x86). Týkat by se měla většiny procesorů Core (minimálně od Sandy Bridge, u starších to ale Intel možná jenom přestal řešit) a Xeon s zřejmě 22nm Atomů Bay Trail a Avoton (architektura Silvermont), ale již ne 14nm Airmontů, Goldmontů a Goldmontů+ a in-order starších Atomů.

Problém spočívá v tom, že za určitých okolností může požadavek směřující do instrukčního bufferu TLB na fetch instrukce najít jako cíl více položek, procesor vyhodí chybu Machine Check Error a výsledkem je, že se zasekne a z tohoto stavu se CPU nemůže vrátit, dokud neprovedete restart. Tuto situaci lze navodit speciálně napsaným kódem, v kterém útočník běžící ve virtualizovaném systému (typicky tedy na serveru) přepne v tabulce stránek velikost stránek (například z 4KB na velké 2MB/4MB/1GB stránky) a režim z lineární adresace na jiný. Mezi tímto přepnutím a okamžikem, než software invaliduje staré záznamy, může útočník iniciovat přístup, kdy CPU při hledání TLB záznamu pro určitou stránku nalezne nový a současně starý záznam, s čímž se neumí vyrovnat a dojde k oné MCE chybě a zatuhnutí. Tento útok může například provést uživatel na virtualizovém systému (cloudový klient), ale odstaví celý fyzický server.

Under this errata, instructions are fetched from a linear address translated using a 4 KB translation cached in the iTLB. Privileged software modifies the paging structure so that the same linear address using large page size (2 MB, 4 MB, 1 GB) with a different physical address or memory type. After the page structure modification but before the software invalidates any iTLB entries for the linear address, a code fetch that happens on the same linear address may cause a machine-check error which can result in a system hang or shutdown.

Opravy této chyby budou implementovány na straně operačního systému. Na Linuxu má tento problém řešení ve formě restrikce, kdy budou velké stránky povolené jen pro oblast paměti, která je označená jako data a nikoliv jako spustitelná, respektive velké stránky budou všechny označené jako nespustitelné pomocí NX bitu. Tudíž jejich data nebudou obsahovat kód programu a tudíž mapování takovýchto stránek nebude cachováno v instrukčním TLB, takže se slabé místo obejde a nestabilita nenastane.

Podrobnosti k chybě iTLB multihit

Snímek čtyřjádrového čipu Skylake (2015)

3. Jump Conditional Code Erratum: opět chyba způsobující pád systému

Třetí problém označený Jump Conditional Code (JCC) Erratum je opět chyba, kdy se procesor jen postaru zasekne či zblázní. Intel uvádí, že důsledkem je tzv. unpredicatble behavior, čímž se myslí, že přestane fungovat podle definovaného způsobu, typicky nastane nestabilita a zamrznutí. Tato fráze se používá u CPU errata už konvenčně. Jaký je přesný spouštěč, Intel neuvádí, má však jít o „komplexní kombinaci“ různých stavů v procesoru. Je logické, že nemůže jít o příliš běžnou situaci, jinak by tato chyba byla již dříve nalezena.

Má jít o problém přítomný už od příchodu architektury Skylake od originálu přes Kaby Lake, Coffee Lake i Comet Lake, postižené jsou také Skylake-X/SP a Cascade Lake v desktopu a serverech. Zřejmě jen úplně nové Ice Lake by už mohlo být bez tohoto problému, není-li v dokumentech Intelu chyba. Seznam postižených architektur je zde ve whitepaperu.

Intel Core i9 9900KS 04
Postižené by měly být všechny procesory s architekturou jader Skylake, i nové Intel Core i9-9900KS

Chyba se může vyskytnout tehdy, pokud nějaká instrukce typu skok/jump (return, podmíněné skoky, ale také skok sfúzovaný v procesoru s jinou ALU instrukcí) překračuje hranice cacheline, které jsou po 64 bajtech. Hranice mezi těmito 64B sekcemi jsou tedy kritickým místem, pokud taková operace přetéká z jedné 64B části do další, může takový skok vyvolat ono nedefinované chování a dojde k pádu nebo záseku. Zdá se, že faktorem v této chybě je microOP cache, tedy cache pro dekódované instrukce, respektive to, jak je konkrétně implementovaná v jádru Skylake. U skoků sfúzovaných s další instrukcí se patrně počítá celá délka dohromady, což zvyšuje pravděpodobnost, že celek přistane na kritické hranici mezi dvěma cacheline.

Ačkoliv Skylake už čtyři roky slouží v poli s touto skrytou chybou a nalezena byla až po delší době, není zřejmě natolik vzácná, aby byla ignorována. Intel vydá aktualizaci mikrokódu, která ji opraví. Nový mikrokód změní chování microOP cache, aby necachovala skoky, které budou splňovat podmínku pro pád. Respektive, z cachování těchto operací budou vyloučeny všechny skoky a sfúzované skoky, které překračují hranici mezi 32B segmenty, takže kritérium je o něco striktnější, také jsou z cachování vyloučeny skoky končící přesně před hranicí. Toto je asi čistě způsobeno omezeními toho, co může pomocí změny mikrokódu být vůbec ovlivněno. Takto vyloučené instrukce procesor bude vždy zpracovávat z instrukčního dekodéru a ne z microOP cache, což obejde problém a chyba nenastane.

Intel instrukce JCC erratum
Instrukční kombinace, které postihuje oprava JCC erratum

Aktualizace mikrokódu proti tomuto erratum tedy zamezí nestabilitě při spuštění nešťastných kritérií, a doporučujeme tedy mikrokódy procesorů aktualizovat. Ať už to uděláte prostřednictvím aktualizace BIOSu desky, nebo eventuálně pomocí aktualizace operačního systému Windows, kterou distribuuje Microsoft (a také Linuxové distribuce) a která je záchranou v případech, kdy výrobce desky už aktualizace BIOSů neposkytuje.

Dopad na výkon typicky v řádu procent

Tato aktualizace ale asi nebude bez dopadu pro uživatele. Funkčně by neměly nastat žádné potíže, ale částečné vyřazení MicroOP cache u některých instrukcí sníží výkon. Častější používání a probouzení dekodérů v jádře asi také může trošku zvýšit spotřebu (microOP cache zvyšuje kromě výkonu i efektivitu), ale toto nemusí být znatelné. Když se procesor přepíná z režimu, kdy bere instrukce z microOP cache, do režimu, kdy procházejí standardně dekodérem, dochází zřejmě také k nějakému výkonnostnímu postihu, takže pokud by v kódu bylo hodně skoků generujících tato přepnutí, může dojít k většímu zpomalení.

Podle Intelu by negativní dopad na výkon měl být od nula do čtyř procent, ovšem připouští, že v některých vymykajících se případech může být zhoršení výkonu mohlo být i vyšší. Na Linuxu už dopad opět otestoval web Phoronix, test s grafy můžete vidět zde. Separátně pak otestoval také to, jak/zda se zhoršil výkon ve hrách.

Intel has observed performance effects associated with the workaround ranging from 0-4% on many industry-standard benchmarks.In subcomponents of these benchmarks, Intel has observed outliers higher than the 0-4% range. Other workloads not observed by Intel may behave differently.

Dopad můžete pocítit víc, než u Spectre

Co je možná dobré vyzdvihnout: tento výkonnostní postih se liší od postihů Spectre, Meltdownu a podobně. U těch bylo zpomaleno přepínání mezi uživatelským režimem a jaderným. Postih tedy nastal při systémových voláních, operacích s diskem, přepínání kontextu. Pokud jste ale třeba spustili Cinebench či enkódování, ale i hry, zpomalení nebylo patrné, protože obecné výpočetní zpracování kódu v rámci jednoho běžícího procesu se nezpomalilo. Ovšem toto „JCC Erratum“ je relevantní úplně všude a tedy je ochrana pomocí mikrokódu aktivní pořád. Ovlivní tedy asi i čistě výpočetní zátěže. Zhoršení výkonu se stále může v některých případech projevit jen nepatrně až neměřitelně, ale často asi může docházet k obecně přítomnému zpomalení procesoru. Je tedy na zvážení, zda chcete riskovat málo časté pády kvůli o trošku vyššímu výkonu. Osobně bych asi doporučoval tuto aktualizaci přijmout, abyste měli jistotu (ale nemám postižené CPU, takže nemůžu říct jistě, že bych se také necukal…).

Kvůli chybě ve Skylake se upravuje chování kompilátorů

Dobrá zpráva je, že Intel se pokusil část výkonnostního postihu eliminovat tím, že do kompilátorů softwaru přispěl úpravami, které změní generování kódu tak, aby se pokud možno vyhýbal potížím. Pokud totiž překladač bude klást skoky tak, aby nesplňovaly kritéria pro tuto chybu a její opravu v mikrokódu, pak se předejde negativnímu dopadu na výkon kvůli deaktivaci microOP cache. Dopad těchto změn kompilátorů (a assemblerů) by měl už být změřený ve výše odkázaném testu Phoronixu.

Intel JCC erratum benchmark
Enkódování videa ve formátu AV1 je případ, kde oprava JCC erratum snižuje výkon. Červeně je výkon s překompilovanou binárkou. V některých případech dokáže úprava překladače vrátit výkon zpět. Zde u enkodéru SVT-AV1 má částečný efekt a enkodér Rav1e bohužel výkon zpět nedostal (Zdroj: Phoronix)

Nevýhoda tohoto přístupu je, že programy budou muset být překompilovány, ve starých programech tuto optimalizaci logicky nenaleznete. Kromě toho je také asi trošku kontroverzní, zda kvůli chybě v jedné mikroarchitektuře ohýbat programy pro všechna CPU, což teoreticky může kód deoptimalizovat (například správné zarovnání skoků může být prováděno vkládáním NOP instrukcí nebo instrukčních prefixů navíc, což může nafouknout kód, takže se hůř vejde do instrukční L1 cache). Toto nicméně asi bude volitelné a za čas, až bude Skylake a jeho derivátů představovat méně aktuální procesor, se zase od tohoto „hacku“ může ustoupit, takže nejde o něco, co by bylo napořád.

Opět chyby v CPU Intel: díry, ale i nestabilita. Opravy zhorší výkon všech Skylake
Ohodnoťte tento článek!
4.8 (96.92%) 26 hlas/ů

15 KOMENTÁŘE

      • Tak Intel o bugách a dírách ví už taky celkem dlouho, ale nic si z toho nedělá a stále vydává další děravé generace.
        A hlavně… kdyby to byla jedna díra, ale ono je to celá plejáda děr a bugů, prakticky řešeto má možná míň děr.
        Jasně, nedělám si iluze, že AMD je čistý, ale v porovnání s tímto … a to si říkám, že to snad už nemůže být horší a další měsíc se dozvím, že mají další nové díry.
        Díky, ale Intel minimálně 2-3 generace nebude v mých počítačích a nebudu je požívat ani na stavby pro jiné lidi

      • “TLB bug byl objeven v Phenomech, ale pochazel uz z K3.” To slyším poprvé, zdroj? (Jinak teda nevím, co přesně se myslí K3…)

        @Wendak
        Ty errata jsou u procesorů běžná věc, zase bych to nebral tak striktně. Ty procesory jsou tak složité, že se nedá simulovat a pak ověřit na křemíku, že je všechno 100% korektní ve všech situacích, různých errata je teď pro každé CPU zdokumentovaných i přes stovku, a typicky jsou dost vzácná na to, aby se daly procesory provozovat bez nějaké opravy, nebo stačí nějak přizpůsobit BIOS, operační systémy a ovladače platformy… Pokud byly ty bugy multihit a JCC objeveny až třeba v posledních 12 měsících, tak asi opravdu není snadné je vyprovokovat. On třeba Ryzen měl podobný crash bug při použití FMA, opravený mikrokódem v prvních měsících, ten evidentně nebylo těžké najít.

        Ty bezpečnostní chyby jsou trochu jiného typu, ty asi vycházejí z přístupu k návrhu těch out-of-order funkcí a spekulace, kdy se různé kontroly prováděly co nejpozději místo co nejdřív kvůli výkonu. To asi ale nebyl “bug”, ale “feature”. Prostě ta škola designu vůbec nepočítala s tím, že by side-channel útoky tohohle typu mohly najednou být reálná hrozba a že se to vymstí. Asi něco jako vědět o globálním oteplování, ale z nějakého důvodu být přesvědčený, že se s tím nemusí nic dělat a nic dramatického se nestane. Eventuálně z toho bude průšvih, ale nedošlo k tomu nějakým nedopatřením nebo přehlédnutím/neopatrností.

          • Veru procesor je zložitá vec takže bez chyb sa to nezaobíde ale začína byť to už troska moc. No zachviľu nám tu aj tak dôjde vladarko a všetkým na vysvetli ako je to vlastne všetko super. Btw dlho sa už neozval začínam mať obavy ci si náhodou nekúpil ryzena a teraz musí chudák riešiť nejaké problémy z biosom alebo co :-/

          • To je s pravděpodobností hraničící s jistotou nějaký omyl, ostatně nikde jinde se ta teorie myslím neobjevuje?. Ono čistě když se na to podíváte logicky to vypadá jako dost velký nesmysl. Kdyby to byl už tehdy léta známý známý problém, tak v tom jádru Barcelona nikdy nebyl a nebyl by odhalený až pozdě během vývojového cyklu, aby si pak vynutil o iks měsíců opožděnou opravenou revizi B3…

            Maximálně tak K6 mohla mít nezávisle jiný bug v TLB, nebo, pokud by to (hypoteticky) byl ten stejný, tak byl nalezen zpětně až po tom objevu bugu v Phenomu.

          • Ja se domnivam, ze je to pouze spatne napsane. Velmi pravdepodobne se jedna o bug, ktery byl objeven v phenomech a zpetne vystopovan az ke K6. Nikoliv o bug, ktery byl objeven v K6 a putoval az do Phenomu. Zrejme nejaka architektonicka slabina radice cache.
            Nemuselo se na to prijit dlouhe roky, vsak sidechannel utoky take cekaly na objeveni 14 let, a dosud nenasly zadne uplatneni v praxi.

            • Jo, to mi přijde asi jako jediná reálná možnost.
              Ale když jsem to zkoušel googlit, tak pro K6 jsem nenašel žádnou zmínku, takže bysh se pořád přikláněl k tomu, že to byla nějaká blbost. Dohledal jsem akorát starej článek na PCTuningu se zdrojovým odkazem na Fudzillu, který už byl nefunkční.

            • tu fudzillu mas nahore a je to 11 let, to uz bude dost problem dohledat.

            • To je podle mě už jenom reference. Píšou to tam tak mimoděk, že IMHO o tom předtím musela být nějaká předchozí nebo samostatná zpráva. Asi se ještě zkusím podívat, jestli ji nenajdu, pokud ten článek teda mezitím nesmazali.

  1. Meanwhile… akcie AMD $41 (nárůst cca 40% za měsíc). Ten brejk $35 byl velmi čitelný trejd, easy money. 🙂
    “Aznohh 8.8.2019 at 21:33
    Jak prolomí hranici $35 tak to bude rychlej fičák k $45-$50.”