Velký průšvih s procesory Intel? Prý se tajně chystá bezpečnostní patch snižující výkon

Bezpečnostní problém ve všech procesorech Intel?

Následující informace jsou zatím nedostatečně potvrzené, tudíž je ještě berte s rezervou. Ona chyba, která by podle souboru dílčích útržků měla v procesorech Intelu být, se zřejmě dotýká TLB procesoru a zřejmě spočívá v tom, že CPU při spekulativním vykonávání kódu může ignorovat oprávnění. To znamená, že kód s běžnými oprávněními se může dostat k paměti s vyššími privilegii, zejména do kódu a datových struktur jádra operačního systému. Jde o zásadní bezpečnostní problém na serverech, ale i na běžných počítačích.

Tuto chybu má zřejmě záplatovat změna správy virtuální paměti, na níž se posledních pár měsíců pracovalo v Linuxu, ale údajně i ve Windows. Jde o oddělení adresních prostorů uživatelského prostoru („userspace“, tedy paměť pro běžné programy) a jádra čili operačního prostoru. Ty byly doposud kvůli výkonu mapovány společně. To má tu zásadní výhodu, že v TLB bufferu procesoru mohou zůstat cachovány informace o tom, která stránka virtuální paměti je namapována na které místo fyzické paměti. TLB je kritický pro rychlost operací s pamětí – jeho chyba v procesoru Phenom revize B2 v roce 2008 vedla po opravě k velkým propadům výkonu.

Během podzimu byla však do Linuxu implementována izolace adresního prostoru jádra od uživatelského prostoru pod označením PTI nebo KPTI (Kernel Page Table Isolation, dřívější vývojové označení bylo KAISER), která oba prostory oddělí – prostor jádra již nebude namapován v adresním prostoru uživatelských procesů jako doposud. Podobná změna je údajně separátně implementována ve Windows 10. Prý by mohla vyjít v rámci lednového záplatovacího úterý a již je v sestaveních „fast ringu“ pro členy programu Windows Insider.

Jak to souvisí s Intelem? Zdá se, že tyto změny správy virtuální paměti (což je zásah do základů systému, který obvykle bývá podnikán se značnou rozvahou a dlouhým testováním) byly učiněny poměrně nakvap kvůli tomu, že jsou potřebné právě pro obejití oné hardwarové slabiny, kdy se proces bez privilegií může dostat do paměti jádra. Oddělení adresního prostoru by tomu mělo zabránit. Patche pro Linux jsou zde, kvůli informačnímu embargu mají ale zatím vycenzurované komentáře a dokumentaci.

PTI znamená zpomalení systémových volání

Problém ale je v tom, že implementace této změny má – což je potvrzeno – zásadní dopady na výkon. Ty se projevují tehdy, pokud vykonávání kódu přeskakuje z programu do kódu v jádře, což je zejména při obsluze systémových volání – například čtení z disku, komunikace po síti, přerušení. Při neizolovaném adresním prostoru mohl takový požadavek proběhnout a vrátit se do programu jednoduše. Nyní ale bude nutné při přechodu tam i zpět vyprázdnit TLB kvůli přechodu do druhého adresního prostoru. Výkonnostní cena systémového volání se tak může přiblížit tomu, co dosud stál tzv. context switch, tedy přepnutí z jednoho programu do druhého.

A momentálně to vypadá, že kvůli oné údajné zranitelnosti procesorů Intelu bude v Linuxu (ale možná i ve Windows) izolace adresních prostorů zapnuta ve výchozím stavu, takže se tyto propady projeví všem uživatelům, kteří operační systém adresují. Nemá se to přitom týkat jen aktuálního Linuxu (nadcházející verze 4.15), PTI bylo backportováno i na větve 4.9 a 4.14, což opět může o něčem svědčit. Výkonnostní dopad zatím není moc jasný kromě toho, že existuje. Mikrobenchmarky měřící přímo dopad výkonu systémových volání ukazují zhoršení o desítky procent (o třetinu až i polovinu), v běhu běžného programu by tyto dopady asi měly být rozředěné. Očekávat by se asi dalo typické zpoždění v jednociferných procentech, ale projevy se pravděpodobně budou značně lišit podle povahy operací. Úlohy s velkým množstvím systémových volání (například příkaz dd na Linuxu) budou mít zásadnější zpomalení. Nezbude než počkat na benchmarky.

Test propadu výkonu v databázi PostgreSQL (zdroj). Výkon procesoru Skylake klesá o 7 až 17 %

Pravděpodobně bude minimálně na Linuxu možné tuto opravu vypnout, ovšem půjde asi o bezpečnostní riziko – jak velké, zatím těžko říct. Možná bude akceptovatelné na desktopu a běžném (třeba herním PC). Na serverech si ale provozovatelé nebudou moci něco takového dovolit. Zda bude funkce PTI přes snížení výkonu ve výchozím stavu zapnutá na desktopových distribucích Linuxu a zda bude tato technika globálně zapnutá i na Windows 10, zatím není jisté.

Efekt opravy podle testu Phoronixu (více zde): Compile Bench obnáší I/O a trpí, naopak x264 nebo FFmpeg (kód silně vytěžující čistě CPU s nízkým podílem systémových volání) zdá se skoro nezpomalila

Vyhnul se problém procesorům AMD?

Izolace adresních prostorů byla zpočátku při vývoji zapnutá jak pro Intel, tak pro AMD. Minimálně podle některých interpretací však zranitelnost, kvůli které bylo PTI vyvinuto, není součástí přímo instrukční sady x86, ale jen architektury novějších procesorů Intel (patrně Haswell, Skylake a novější, možná i starších). AMD zaslalo do jádra Linuxu patch, dle kterého příslušnou zranitelností netrpí, PTI tedy nepotřebuje a může na jeho procesorech být vypnuto.

Podle AMD nejsou jeho procesory zranitelné jako ty od Intelu a PTI by u nich mohlo být v Linuxu vypnuté, pokud bude tento patch přijat. Zda se propadu výkonu vyhnou i na Windows, zatím nevíme

Zda ale bude tato změna přijata a AMD dostane výjimku, zatím také není jisté (pokud by ji nedostalo, můžete PTI ještě ručně vypnout volbou -nopti), stejně tak není jasné, zda dostane výjimku na Windows. Nicméně pokud se toto potvrdí, pak by mohla nastat situace, kdy výkon prakticky všech Intelů klesne, zatímco u procesorů AMD zůstane stejný, a tedy budou proti konkurenci relativně rychlejší než dříve. Ovšem opět opakuji, bude třeba počkat, až se všechny momentální nejasnosti lépe ozřejmí. Podobě zatím není jasné, kterých procesorů Intel se bezpečnostní problém týká, pravděpodobně ale minimálně všech současných a zpětně snad i Sandy Bridge, Ivy Bridge, možná i dřívějších.

Aktualizace:

Zdá se, že výjimka z PTI pro procesory AMD prošla do hlavního repozitáře Linuxu (snad má směřovat do jádra 4.15rc6), pokud se nemýlím. Výkonnostní dopad by tedy pro čipy AMD minimálně na Linux být neměl, u Windows stále není jasno.

Víc informací snad už brzy

Zveřejnění této bezpečnostní chyby pravděpodobně nastane během několika dní. Máme o tom indicie například ze strany Microsoftu, který začal uživatelům cloudu Azure rozesílat zprávy sdělující, že 10. ledna bude instance běžící na něm restartovat kvůli bezpečnostním aktualizacím. Něco podobného údajně bude i u IBM a u Amazonu a na 4. ledna údajně vyjde i nějaké „Security Advisory“ od Xenu, které by se mohlo týkat tohoto problému. Opravy a přípravy na jejich nasazení probíhají pod informačním embargem, což by mohlo indikovat, že potenciální problémy nejsou malé. Po zveřejnění detailů by zřejmě mohlo být více jasno v tom, jak moc se nás opravy a propad výkonu dotknou a snad také v tom, zda opravdu budou postiženy jen procesory Intel.

Oznámení Microsoftu, dle kterého budou kvůli nasazování opravy do provozu restartovány instance cloudu Azure

Staré recenze přestanou platit

Zvlášť pokud by se potvrdila domněnka, že procesory AMD opravu nepotřebují (v kterémže případě doufejme pro ně nebude vynucována), vznikne docela prekérní situace u existujících recenzí a testů výkonu. Ty pořízené na starších operačních systémech s exponovanou zranitelností už nebudou reprezentovat skutečný výkon na počítačích s opravou. Mezi jednotlivými opatchovanými procesory se také mohou měnit relativní rozdíly výkonu, pokud na některých architekturách postih bude nižší, než na jiných. V podstatě asi bude třeba vše přeměřit a starší testy procesorů lze hodit do koše. Pro definitivní závěry ovšem vyčkejte, až bude vše zveřejněno a dovysvětleno, musíme opět zopakovat.