Díry v CPU: Zen 3 má zneužitelný Predictive Store Forwarding. Podle AMD je riziko malé

26

Jednou z ingrediencí vysokého výkonu procesorů AMD Zen 3 je zdá se spekulativní funkce Predictive Store Forwarding. Bohužel také otevírá novou zranitelnost.

Dlouho jsme nepsali o bezpečnostních problémech v procesorech (ne že by se žádné side-channel útoky neobjevovaly, ale zdá se, že se to již stalo součástí normálního běhu věcí). Teď ovšem byla publikována bezpečnostní chyba, která ukazuje, že stereotyp, podle kterého jsou „děravé“ Intely oproti bezpečným alternativním CPU, není moc užitečný. Minimálně část z těchto útoků na spekulativní vykonávání kódu je vedlejším produktem samotné podstaty fungování procesorů a nepředstavuje „selhání“ Intelu.

AMD teď publikovalo dokument, v kterém prezentuje jedno z výkonnostních zlepšení v architektuře Zen 3, tzv. funkci Predictive Store Forwarding. A důvodem je zřejmě ani ne tak chlubení, jako hlavně, že tato technika podobně jako další spekulativní optimalizace v procesorech otevírá cestu k bezpečnostním útokům typu Spectre. Jde o nové architektonické zlepšení (míněno po stránce výkonu), takže momentálně je takto zranitelný jen Zen 3 a ne předchozí architektury. Tedy Ryzeny 5000 (mimo mobilní APU Lucienne) a Epyc 7003 Milan.

Predictive Store Forwarding

Predictive Store Forwarding navazuje na běžně používanou funkci Store to Load Forwarding. To je technika, s níž procesor identifikuje situace, kdy kód čte z paměti stejnou adresu, na kterou předtím bylo něco zapsáno, respektive něco čeká ve frontě na zapsání. Pokud procesor má tuto zapisovanou hodnotu ještě v bufferech, může jí rovnou předat následné čtecí operaci. Přístup do paměti, který normálně stojí stovky cyklů času, se tím obejde a výsledkem je velké zlepšení výkonu.

Predictive Store Forwarding k tomuto přidává další úroveň, která funguje v momentě, kdy je možné, že by se dal tento Forwarding použít, ale ještě nebyly vyhodnocené podmínky ukazující, zda k situaci opravdu dojde (tedy ještě není potvrzeno, že se adresa dat v paměti shoduje).

Predictive Store Forwarding proto funguje spekulativně – dodá daná data předem pro případ, že správně uhodne, co kód za chvíli bude chtít. To dobře funguje třeba ve smyčkách, kdy je pravděpodobné, že se bude opakovat vzorec z předchozí iterace. Pokud by se spekulace netrefila, vše je vráceno zpět.

graficke karty metodika 13
Procesor AMD Ryzen 9 5900X (Zdroj: HWCooling)

Právě případy chybného odhadu jsou ovšem zranitelné na útoky. Podobně jako predikce větvení a další takové techniky je možné, že chybná spekulace zanese do cache procesoru data ze špatné adresy. A pokud je na tuto situaci napsán speciální škodlivý kód, může se k těmto datům v cache dostat, než je procesor zase zahodí.

Kvůli tomuto riziku nyní AMD publikovalo MSR registry, s nimiž bude operační systém moci toto chování procesoru dočasně vypnout v situacích, kdy by mohlo hrozit napadení – typicky by to mohlo jít u prohlížečů, které spouštějí javascript z webových stránek, který by mohl obsahovat útočný kód. Povaha chyby je podobná zranitelnosti Speculative Store Bypass (Spectre v4), takže ochrana by asi měla být aktivována v podobných situacích.

Poměrně potěšitelný detail je, že zranitelnost Predictive Store Forwarding funguje jen v rámci jednoho vlákna procesoru, protože stav spekulativního prediktoru má každé vlákno vlastní. SMT tedy touto zranitelností není postiženo. Chyba také není zneužitelná, pokud se přechází mezi separátním adresními prostory, takže virtuální stroj se například dá ochránit použitím funkce Secure Encrypted Virtualization (na Epycu 7003).

Riziko je prý jen malé

Nebezpečnost je podle AMD malá („low“), takže pro běžné uživatele je doporučeno nechat procesor ve výchozím stavu, což nemá způsobovat vážnější riziko. Optimalizace Predictive Store Forwaring zůstává ve výchozím stavu aktivní, čili nedochází ke změnám výkonu.

AMD recommends leaving the Predictive Store Forwarding feature enabled as the default setting.

Pro enterprise a serverové uživatele je možné použít zmíněnou separaci adresního prostoru. V případě, že to nelze, je pak možné použít ony kontrolní registry k deaktivaci PSF, což zneužití znemožní za cenu nějakého výkonu. Negativní dopad by snad neměl být velký, soudě podle testu Phoronixu. Nejhorší propady v ojedinělých případech jsou prý do 1–2 %. Toto opatření vypínající PSF lze na Linuxu zapnout zvlášť, ale je také implicitně zapnuté vždy, pokud uživatel aktivuje ochranu před chybou Speculative Store Bypass (v takovém případě má ale také výkonnostní propad této mitigace, který je větší).

Propad výkonu procesoru s architekturou Zen 3 vlivem vypnutí funkce Predictive Store Forwarding
Propad výkonu procesoru s architekturou Zen 3 vlivem vypnutí funkce Predictive Store Forwarding (Zdroj: Phoronix)

Na Linuxu se ochrana zapíná parametrem jádra psfd. Parametr mitigations=auto nyní ochranu psfd nezapíná, v defaultním nastavení ji tedy Linux neaplikuje, dle doporučení AMD.

Parametry Linuxu ovládající ochrany proti zranitelnostem Predictive Store Forwarding a Speculative Store Bypass
Parametry Linuxu ovládající ochrany proti zranitelnosti Predictive Store Forwarding (Zdroj: AMD)

Spekulativní forwarding asi nebude výsadou Zenu 3

Ačkoli zatím byl problém publikován jen u Zenu 3, spekulativní provádění store-to-load forwardingu zřejmě není unikátní vlastností této architektury. Podle patentů by totéž měly dělat například i jádra Apple. Nemáme zprávy o tom, zda už podobnou predikci a spekulaci dělají i aktuální jádra Intelu (Ice Lake/Tiger Lake/Rocket Lake), ale je asi pravděpodobné, aby takovéto optimalizace nyní nebo v budoucnu Intel nasadil také.

Tyto procesory asi pak také budou mít podobný mechanismus na deaktivaci této spekulace a podobné (volitelné) ochrany. Zřejmě půjde stejně jako u prediktoru větvení (Spectre V2) o potenciálně zranitelnou věc, která ale v procesorech je třeba.

Galerie: AMD Epyc 7003 Milan: odhalení

Zdroj: AMD

Díry v CPU: Zen 3 má zneužitelný Predictive Store Forwarding. Podle AMD je riziko malé
Ohodnoťte tento článek!
5 (100%) 7 hlasů

26 KOMENTÁŘE

  1. Tyhle díry jsem nikdy nepochopil. Chápu, že spočívají v tom, že jedno vlákno může přečíst hodnotu paměti, ke které by nemělo mít přístup. Ale absolutně nechápu, jak ví, na které adrese je něco tajného a dokáže poznat, co to má být.

    • V minulosti u Intelu jsem to chapal tak, ze nedokaze. Tady to bude stejne. V systemu musi byt jeste neco, co prave bude hlidat to, kde se ta zajimava data v pameti nachazi a toto „spectre“ potom dostane za ukol je precist nebo pozmenit. Kvuli moznosti zmeny tam Intel integroval nejaky kontrolni kod, ktery kdyz se zmeni, tak se data zahodi, AMD to nebude mit jinak, takze zustava jen ta moznost precteni.
      Jak pise Jan Olsan, proste je to dan za vykon procesoru a nebezpeci to je maximalne pro nejakou kritickou infrastrukturu, navic se to da vypnout a snizit si vykon. Domaci uzivatel rozhoden neni ohrozeny. U Intelu tam byl jeste problem, ze se z jednoho vlakna dalo cist jine a pokud byl na kazdem vlakne jiny virtualni pocitac (zase se netyka domaciho uzivatele), mohl jeden cist data druheho. Tady to ale take neni mozne.

    • To asi nemusí dopředu vědět, stačí když při pátrání například po šifrovacích klíčích AES-128 vyzkouší všechna získaná cizí data tj. otestovat relativně omezený počet (miliardy) kobinací klíčů což je podstatně rychlejší než brute force útok na 340 282 366 920 938 463 463 374 607 431 768 211 456 možných kombinací. Klíčový budei rozsah a rychlost takto získáných dat. Například u zranitelnosti Spectre kdysi demonstroval Google v Chrome těžbu cizích dat rychlostí cca 1kB/s (tj. 86MB/den, takže například při velikosti paměti 8GB je tu teoretická pravděpodobnost 1:100, že se k datům s uloženými klíči za den dostanu.

      • Takže s pravděpodobností 1:100 se za den dostanu k nějakému klíči. Ale vůbec netuším, jaký klíč to je a k čemu ho můžu použít. Asi jako když v Praze na Václaváku ztratím klíč od baráku a někdo ho najde. Ve skutečnosti tedy spíš nenajde jen můj klíč, ale miliony různých klíčů, co vypadají jako klíče, ale k ničemu nepasují. A ten zloděj pak začne obcházet všechny zámky a zkoušet, jestli do nich nějaký ten klíč nepasuje.
        Prostě pořád si nedovedu představit reálnou hrozbu, kterou by tyto chyby měly způsobit. Teoreticky to samozřejmě můžu demonstrovat, ale při té demonstraci používám znalosti, které ten škodlivý kód nemá. Tedy demonstruju to na svém počítači, kde vím, že je uložený šifrovací klíč ke konkrétní službě konkrétního uživatele a ukážu, že ho ten škodlivý kód dokáže s jistou pravděpodobností najít.

        • Tyhle utoky jsou spise teoreticke a „minig“ by trval dlouho, jak popisuje PetebLazar. Tedy normalni uzivatel by mel byt relativne v bezpeci, pokud nema osobni pocitac zapnuty 24/7 s bezicim virem z nejakeho javascriptu, ktery posila vsemozne info o aktivitach na pocitaci. Celkove to ale neni trivialni problem a ukrast nekomu klic je teoreticky mozne, prakticky spise ne.
          U serveru je to trosku vetsi problem, protoze hosting nemuze jen tak restartovat servery a mazat tak nejruznejsi cache a pameti. Tam ty servery – virtualky – musi bezet 24/7 a separace dat mezi nimi musi byt maximalni az absolutni.

          • Tady bych vypíchl ale jednu věc – dnes je módní PC jen uspávat a typická Windows10 typického BFU mají uptime i stovky hodin.

            Přiznám se, že jsem nepátral po tom, zda takový kód dokáže bez problémů přežít spánek nebo hibernaci, ale minimálně u S1 jsem si téměř jist, u S3 už tak úplně ne.

    • Kdyz se to u Skylaku odhalilo, tak se mimo jine rikalo, ze je to konec provadeni spekulativniho uhadnuti kodu. Tahle technika bude opustena.
      Ubehlo par let a AMD tu techniku zase nasadilo. Proc? Protoze to zvysuje vykon na ukor maleho rizika bezpecnosti. Neni to vhodne do kriticke infrastruktury, ale domaciho uzivatele vic potesi ten vetsi vykon.

      • Víte to jak „malé“ je to riziko nám dokázal Intel když záplaty na to jejich malé riziko se spektrem a meltdownem které značně snižovaly výkon jejich procesorů. Ruku na srdce „tedy jestli to jsou opravu dvě procenta“ tak mi nestojí za to aby mi třeba někdo naboural do plateb hacknul mail, … Víte ono se vážnost problému doopravdy ukáže až to někdo zneužije ne když to někdo ohlásí. Kdo doopravdy pozná 2% výkonu svého procesoru?

        Možná jsem zbytečně vyděšený ale výrobci procesoru vždy bagatelizovali své přešlapy

        • Souhlas, pokud nepotřebujete maximální výkon, ale stačí vám maximální – 1, tak to trvale vypnout. Ale jinak si myslím, že ideální by byla možnost ručně aktivovat fíčuru pro procesy, které ji využijí a zároveň nejsou bezpečnostím rizikem. Tedy pro hry, zpracování multimédií atp. Pro vše ostatní (browser, IM, pdf reader, office,..) to není buď potřeba a nebo jde o riziko, tam to vypnout. Osobně bych preferoval možnost whitelistu procesů, kde preferuji maximální výkon. Na vše ostatní je preference bezpečnost. Na druhou stranu, běžný počítač v rukou BFU má řádově jednodušeji zneužitelné díry. Neaktuální OS, zastaralé wifi AP, mizerná hesla, návštěva pochybných webů, klikání na phishing atd. Je to podobné asi jako, že zloděj se nebude babrat s vložkou zámku když může zámek přestřihnout, zmrazit, utrhnout petlici nebo vysadit dveře. Nezlehčuju problém spekulativního vykonávání, jen je třeba se zaměřit na reálnou zneužitelnost a ta je jinde.

          • A nepřipadá Vám to řešení procesního whitelistu poněkud krkolomné a nekoncepční? První dvě věci co mne napadly je jakou by to mělo režii. Aby to nepřekročilo ty dvě procenta zátěže. Mohlo by to pak být náročnější než vypnutí této fíčury. Druhá věc to mi vrtá hlavou aby někdo ten whitelist nehacknul.

            • Samozřejmě, že je to krkolomné a nekoncepční. Ale takový je dnes celý svět. Tesla narazí do překážky a přesto je takový SW puštěn na silnici. CPU se vzdá části bezpečnosti výměnou za vyšší výkon. Takže je fér, aby pak uživatel si mohl vybrat co preferuje. Upřímně, default by byl výkon. Kdo chce přepne na bezpečnost. A kdo se cítí jako poweruser, dostane možnost řízení na úrovní aplikací. Takových možností je ve win tuna a linux je takový celý. Tak o co jde?
              A pokud by se někdo dostal k whitelistu, tak měl přístup do systému s admin právy, tam už je to snad jedno ne? Asi jako kdyby zloděj byl u vás doma a vás nejvíce trápilo, že si možná udělal kopii klíče k zámku.

        • jak velké je to riziko se prokázalo v březnu tohoto roku (2021), kdy byl zaznamenán první používaný a funkční profesionální malware na zranitelnosti Spectre, kupodivu pro linux, kde to dokaze dumpnout /etc/shadow. Spectre byl objeven v roce 2018.

      • Redmarxi, zapoměljsi dodat, že jakmile se obejvil problém u intelu, byla tady celá squadra AMD bojovníků, kteří hejtovali intel, že je to KATASTROFA !!! Že to JE PODVOD NA zákázníky, kteří si koupili výkon a ten se jim nějakým způsobem bude zmenšovat o 0-3% (v reálu to bylo neměřitelných 0-0,5% což bylo pod úrovní chyby měření).
        Ale teď je to na AMD a je tu ticho?
        Nikde ani hláška o tom, že je AMD fuj, že pokud příjde za půl roku oprava mikrokodu, že to sníží výkon a zákazníci AMD byli podvedeni ?
        Jasně to ukazuje červenej hadr na xichtu, zalezlí někde v noře potichu a čekají že si toho nikdo nevšimne. Nebo ten damage control Alicha: „však co, dokud tu bude sdílená paměť tak tu bude ten problém vždycky“.
        Najednou to nevadí, najednou to není chyba, ale vlastnost. Ale když to měl intel tak to byla chyba. Jasně to ukázuje, naše české švejkování, kam vítr tam plášť.

        • Pan Jaroslav Crha 10.4.2021 at 19:21
          1. Meltdown je uplne jina liga a je realne docela jednoduse zneuzitelny. Mimochodem asi byste se divil, ale vedelo se o tom HODNE dlouho, nez se to dostalo na verejnost. Muzu rici, ze z toho nejen inzenyri, ale cela oddeleni nespala. To byl problem pouze Intelu.
          2. Dalsi problem mel opet ciste pouze Intel s jistym “Spectrem”, u ktereho se vypinal HT, protoze to bylo opet relativne jednoduse zneuzitelne. Propad vykonu byl myslim kolem 30%? Uz presne nevim.
          3. Lehci verze Specter mel, ma a bude mit jak Intel, tak AMD, Apple a ARM. O tom se ted a tady bavime, Crho. Tyto se normalniho uzivatele nedotknou a i u serveru to muze byt volitelne nastaveni, protoze zneuzitelnost uz je velmi obtizna.
          Takze nez zacnete s nejakym damage control, tak nejdriv hodne studujte a pak se pridte bavit.

        • Trochu pravdu mas, ale ne uplne.
          Prvne propad vykonu byl po oprave MeltaSpektra citelny, tipnul bych to na ~10%.
          Druha vec s tim, jak fanousci AMD radili kvuli tezko zneuzitelnemu designu, tak ano, take si to pamatuju, delali tu jak sileny, bylo to k smichu. Jenze casem se ukazalo, ze jedna z tech chyb, ted uz nevim ktera (Melta, Spektra v1, Spektra v2) je zneuzitelna vzdalene, slozite ale slo to, takze nakonec to problem byl znacny!

          • Ja bych jen doplnil ze jak kde. V desktopu mel nejvetsi dpad Meltdown na I/O, tedy u rychlych ssd. Prakticky to neslo poznat, ale v syntetestech to bylo u nekterych mereni desitky procent. V praxi nula.
            Stejne tak v desktopu u Spectre. Prakticky dopad nula – kdo to videl v realu byli lidi co delali kompilace velkych projektu.
            Nicmene vzhledem k nulovemu zneuziti spectre v praxi to stejne tenkrat ti co to nejvic pocitili proste vypli. Stejne jako dnes.

        • Já to vrátím do věcné roviny:
          1. Ano, je to problém, a bude třeba problém řešit minimálně u serverů.
          2. Jedná se o Zen3 arch, takže dopad je (zatím) poměrně malý a podchycený v samotném začátku, navíc AMD nic nezastírá a poskytuje několikeré řešení problému.

          Osobně jsem zvědavý, jestli se chyba objeví i v Zen3+?

  2. Dokud tu budeme mit „predikci dat a jejich udrzovani v pameti“ s nemoznosti jasne separovat datovy prostor danemu procesu primo v „prediktoru“, nebo jinak znemozit cteni dat napr. pomoci sifrovani s bezpecnym ulozenim a pouzitim klice, tak tu Spectre bude s nami 😉