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

Brzy tomu budou dva roky, co se provalily bezpečnostní problémy či díry v procesorech nazvané Meltdown a Spectre, 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ě

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.

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.

Již 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)

• 
• 
• 

Dalších 6 fotografií

Podrobnosti k chybě TSX Asynchronous Abort

• Informace Intelu
• Informace Cyberus Technology
• Informace pro Red Hat Linux
• Aktualizace Windows proti TAA

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

• Informace od Intelu
• Informace pro Linux na Kernel.org

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.

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.

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.

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.