Pouze Meltdown je konkrétně chyba zabezpečení a designu společnosti Intel.
Aktualizace: zdá se, že AMD je vůči Spectre většinou odolná. Není jasné, proč by tomu tak bylo. Ale podle AMD:
(od začátku ledna, nyní nahrazeno, viz aktualizace 2 níže)
Rozdíly v architektuře AMD znamená téměř nulové riziko využití této varianty. Zranitelnost varianty 2 (Branch Target Injection) nebyla dosud u procesorů AMD prokázána.
Všimněte si, že je to jen „téměř nula“, na rozdíl od „nula“ pro Meltdown. (A že útok „Spectre v1„ Bounds Check Bypass “(podmíněná přímá větev před přístupem do pole) je stále třeba opravit v softwaru.)
Aktualizace 2 : AMD může mít podceňovaný Spectre, protože stále vydávají aktualizace mikrokódu a jejich web now říká:
Varianta 2 GPZ (Branch Target Injection nebo Spectre) je použitelná pro procesory AMD .
- I když věříme, že architektury procesorů AMD ztěžují využití varianty 2, nadále úzce spolupracujeme s průmyslem na této hrozbě.
Stále není jasné, jaké vlastnosti / rozdíly v mikroarchitektonickém designu činí procesory AMD odolnějšími než Intel; stále mají velké okno mimo pořadí a AFAIK nejsou výrazně omezenější v tom, co může být v letu najednou. Ale jejich prediktory větví jsou navrženy odlišně a je obtížné je špatně trénovat nebo jsou nějak izolovány přes hranice privilegií? Ten druhý by je ale také imunní vůči Spectre v1 a procesory AMD jsou stejně zranitelné vůči verzi Spectre s obtokem hranic.
Spectre (v2) ovlivňuje jakýkoli „normální“ design CPU s predikcí větve + spekulativní provádění pro nepřímé větve. Ve Spectre útočník připraví / vycvičí prediktor větve, aby předpověděl cíl nepřímé větve v kódu jádra nebo v jiném procesu. Dokud nebude odhalena chybná předpověď, privilegovaný proces spekulativně provede některé pokyny, které změní mikro -architekturní stav stroje způsobem, který závisí na tajných datech.
( Poté útočník použije útok načasování mezipaměti ke čtení tohoto mikroarchitektonického stavu, stejně jako v Meltdown. Při útoku na jádro byste si v ideálním případě vybrali „gadget“, který pomocí tajných dat indexuje pole vašeho útočícího kódu v uživatelském prostoru také má oprávnění ke čtení. Pokud nemůžete, možná budete muset použít útok načasování vystěhování z mezipaměti, abyste místo hledání řádku, který se stal horkým, vyhledal, které sadě mezipaměti byl řádek vystěhován.)
Defeat Spectre in HW might take something as costly as fluds the branch-predictor caches on every transition across trust boundaries. Nebo alespoň vyrovnávací paměti predikce cíle nepřímé větve. (kernel / user is one the HW is aware of, but into sandboxed JIT-compiled code (specifically Javascript) is a problem.)
Klíčem k Meltdown je, že procesory Intel (ale zjevně ne ARM nebo AMD) neškrábejte nedostatečně privilegované zásahy TLB. Zátěž se spustí, stejně jako následující pokyny, a ve skutečnosti se poruší pouze tehdy, když se vadná zátěž pokusí odejít To umožňuje neprivilegovanému kódu přímo způsobit změny v mikroarchitekturním stavu samotném na základě dat, která nemá oprávnění ke čtení, místo toho, aby (Specter) přiměl privilegovaný proces, aby to provedl.
(Upozorňujeme, že skutečná data získáte pouze v případě, že linka byla již v mezipaměti L1d horká; zdá se, že na procesorech ani opakované útoky Meltdown na stejnou linku nezpůsobí, že CPU přinese linku do mezipaměti, pokud už tam nebyl.)
;; spusťte to v uživatelském prostoru ;; (a potlačit nebo chytit poruchu nějak, abyste to mohli udělat rychle / opakovaně) ;; clflush všechny řádky mezipaměti v local_array (které máte oprávnění číst) ;; vytvořte dlouhé zpoždění, než mohou následující pokyny odejít do důchodu, ale s několika uops, takže OoO exec může vidět kolem ittimes 30 sqrtpd xmm0, xmm0; vysoká latence na uopmovzx eax, byte [kernel_byte]; nakonec chyby, ale OoO exec pokračuje firstshl eax, 12mov eax, [local_array + rax]; řádek mezipaměti, kterého se to dotkne, závisí na tajných datech ;; po chybách movzx bude řádek mezipaměti, kterého se dotýká mov, stále horký; pak zkontrolujte, který řádek mezipaměti local_array je již horký.
(A BTW, poslal jsem o tom autorům Meltdown paper. Byli ve spěchu zveřejnění do data zveřejnění, které se zjevně neočekávaně posunulo o 1 týden. Plánují vyjasnit svůj oddíl o mikroarchitekturních detailech, aby bylo jasné, že toto je skutečná chyba designu, která umožňuje Meltdown.)
(Meltdown závisí na tom, aby jádro udržovalo své stránky namapované na virtuální adresový prostor procesu, ale s trochou nastavenou v položkách tabulky stránek, které je označují jako mapování pouze pro jádro. Díky tomu jsou systémová volání a přerušení levnější, protože Není nutné upravovat tabulky stránek, aby umožňovaly přístup k paměti jádra: CPU právě začíná umožňovat, aby tato mapování pouze pro jádra fungovala, když běží v kruhu 0. Viz tento Q&A pro schéma stránky x86-64 vstupní formát. Bit U / S (uživatel / nadřízený) je ten, který řídí, zda je mapování provedeno pouze jádro nebo ne.)
Porucha, která je nakonec vyvolána, je buď zpracována (chytit SIGSEGV), nebo potlačena (spustit přechodnou sekvenci uvnitř transakce TSX (transakční paměť) nebo v důsledku chybné spekulace). V Meltdown jsou tedy nesprávné předpovědi větví relevantní pouze jako součást zefektivnění a spolehlivosti útoku potlačením chyby na zátěži z virtuální adresy jádra. Spekulativní provedení za chybnou zátěž je klíčové, dokonce i pro závislou instrukci. (Nejen pro nezávislé instrukce provedené dříve, než je připravena adresa pro načtení, nebo cokoli tak jednoduchého.)
Pravděpodobně jsou jednotky pro spuštění načítání / TLB AMD navrženy odlišně, s kontrolou oprávnění pro načtení použity dříve nebo odlišně . Buď se načtením z virtuální adresy s mapováním pouze pro jádro zachází stejně jako se načtením z nezmapované stránky, nebo jsou bity fyzické stránky použité pro spekulativní spuštění nastaveny na nulu nebo vše-jeden nebo tak něco. Nebo možná jen zmáčkne zátěž, aniž by spustila procházení stránky (jako by to bylo načtení z nezmapované stránky).
Všimněte si, že x86 nevyžaduje zneplatnění TLB při změně záznamu tabulky stránek z neplatného na platný , takže hardware pro překlad adres nesmí provádět „negativní“ ukládání do mezipaměti. Nebo pokud ano, muselo by to být v souladu s zápisy v tabulce stránek, díky nimž jsou dříve neplatné položky platné. Procesory Intel provádějí určitý druh sestřelení TLB, aby zachovaly soudržnost pro položky TLB, které byly načteny pouze spekulativně, což jde nad rámec toho, co vyžadují příručky x86, aby nedošlo k rozbití starého kódu, který existoval před zveřejněním aktuálních pravidel zneplatnění TLB (např. Win95 až ME).
Jde o to, že jiná volba mikroarchitekturního designu by mohla úplně zablokovat to, na čem závisí Meltdown . A takové možnosti designu jsou věrohodné samy o sobě, nikoli konkrétně proto, aby se zabránilo Meltdown.
Související otázka: proč má volba zpožděného povolení kontroly designu od Intelu smysl?
Až do Meltdown / Spectre se designéři CPU obávali pouze toho, aby zajistili ochranu paměti aplikovanou na architektonický stav (nespekulativní hodnoty v architektonických registrech, nikoli fyzické registry používané při provádění mimo pořadí). tj. tento postranní kanál nebyl na nikom radaru. Výsledky provádění instrukcí se nestanou architektonickým stavem až do odchodu do důchodu, takže to je bod, kdy musí být vše správné (v uvažování před Meltdownem).
Jako návrhář CPU chcete, aby vše probíhalo jako co nejefektivněji a s co nejmenším počtem zvláštních případů. Nebo zejména se zvláštními případy v co nejmenším počtu komponent. Pro celkový design je jednodušší, pokud se výkonová jednotka nikdy nezastaví, takže zřetězená část logiky nepotřebuje žádné řízení toku, jednoduše vždy přijměte jeden nový vstup na hodiny.
(Aktualizace: alternativou k pozastavení je hlášení poruchy. Načíst výpadky v procesorech Intel již mohou hlásit selhání zpět plánovači OoO a je třeba je znovu přehrát. Dochází k chybám mezipaměti L1d a k detekci (během výpočtu adresy) mezipaměti -line split (pro získání dat z druhého řádku mezipaměti), nebo pokud se port pro načítání pokusil použít speciální případ latence 4c pro jednoduché režimy adresování , ale skutečná adresa byla na jiné stránce než základní zaregistrujte se. A dokonce i přehrání dalších uops závislých na nákladu, které byly odeslány v očekávání, že náklad v určitém cyklu způsobí svůj výsledek. Chybějící mezipaměť způsobí, že Teoreticky by tedy tento mechanismus mohl efektivně nevytvářet hodnotu pomocí nedostatečně privilegovaných zátěží.)
Vypadá to, že současné jednotky Intel pro provádění načítání nemají způsob, jak zmáčknout zátěž při zásahu TLB. Samotný TLB je CAM (Content-Addressable Memory). Správa záznamů TLB se spekulativními procházeními stránek (předběžné načítání) vyžaduje aktivnější hardware, ale samotný TLB musí být rychlý, aby podporoval 3 vyhledávání za hodinu (z portů 2, 3 a 7).
Většina kód nezpůsobuje chybu stránky pokusem o načtení z adres jádra, takže optimalizace pro tento případ nebyla v úvahu. Pokud jsou takové načtení viditelné při provádění mimo pořadí, obvykle k nim dochází v důsledku chybné spekulace (spuštění instrukce načtení s nesprávnými daty v registru). (Není nutně zlomyslně chybná spekulace (Spectre), pouze běžný druh z nedokonalé predikce větve.) Nedělat nic s chybným zatížením zasaženým TLB až do odchodu do důchodu je dobrým designovým rozhodnutím, pokud Většinu času nikdy nedosáhne důchodu, protože nesprávná předpověď pobočky nebo jiná nesprávná spekulace je zjištěna dříve v důchodu v pořadí . Ztráta šířky pásma zatížení a způsobení znečištění mezipaměti je sporná, ale (kromě útoků Meltdown) je to pravděpodobně docela ojedinělý případ, takže udržování jednoduchého hardwaru bylo tím nejcennějším.
Obvykle dochází k chybám stránky kvůli přístupu na adresu, která není vůbec mapována: položka tabulky stránek je označena jako neplatná, nejen pouze pro jádro. Nebo je dokonce neplatná i vyšší úroveň čtyřúrovňových vnořených tabulek stránek, např. položka adresáře stránky. Jak již bylo zmíněno dříve, negativní ukládání do mezipaměti není architektonicky povoleno (a AFAIK se nedělá ani snoopingem pro správnost), takže takové PTE se nikdy neobjeví v TLB. Porucha stránky pro nezmapovanou stránku bude vyvolána až po procházení stránkou (která najde mapování pro tuto stránku neexistuje). x86 má vyhrazený hardware pro procházení stránek, takže načtení tabulky stránek se může odehrávat na pozadí, zatímco prováděcí jednotky provozují další uops. (Skylake má dokonce dvě jednotky pro procházení HW stránek). Ale stejně,
Takže chyba stránky při pokusu o čtení mapování pouze pro jádro je speciální případ, velmi odlišný mikroarchitekturně od případu nezmapované stránky. (Je to vlastně podobné, jako když se pokoušíte ukládat do mapování jen pro čtení, které pravděpodobně také zpozdilo chybování. Obchody se hned nestanou globálně viditelnými; vyrovnávací paměť úložiště umožňuje spekulativní provedení obchodu tím, že je ponechá soukromé až po odchodu do důchodu, kdy mohou se zavázat k L1D).
Jak by mohla společnost Intel opravit Meltdown v budoucím hardwaru?
Oprava Meltdown je relativně snadná (ve srovnání s Spectre), i když to s aktualizací mikrokódu pravděpodobně nejde. Stejně jako nastavení bitu chyby-li / když-to-dosáhne-odchod do důchodu na uop, vyhledávání TLB může bránit bity adresy stránky (všem) pomocí kontroly oprávnění. např. načtení v uživatelském prostoru z jakékoli stránky jádra by se mohlo mikroarchitekticky provést jako načtení z nejvyšší fyzické stránky. (A systémy s méně než maximálním množstvím paměti RAM by na této fyzické adrese neměly žádnou fyzickou paměť RAM.)
Nebo neúspěšná kontrola privilegií by mohla ještě umožnit mikroarchitekturní provedení zátěže, ale maskovat výsledek na nulu v zaváděcím portu. (Pamatujte, že problém Meltdown není v tom, že neprivilegovaná zátěž může přinést data jádra do mezipaměti, ale v tom, že výsledek tajného načtení dat lze použít k dalšímu načtení s adresou závislou na datech. provedení s nulovým výsledkem pro jakékoli nedostatečně privilegované zatížení, které zasáhne TLB, by neumožnilo žádné mikroarchitekturní efekty závislé na datech).
Vyhledávání TLB probíhá souběžně s indexováním mezipaměti VIPT L1D, ale výsledek TLB je nutný pro část kontroly mezipaměti L1D s kontrolou značek. Vyžadování výsledku vyhledávání TLB je tedy již nutné pro výběr správné cesty ze sady indexované adresovými bity 6 až 11. (L1D je 8cestná sada asociativní). Takže také vyžadovat, aby byla kontrola oprávnění TLB připravena tak brzy, by neměla zavádět žádnou další latenci. Maskování s výsledkem povolení by zavedlo jedno dodatečné zpoždění brány, ale jeden hodinový cyklus má čas na mnoho zpoždění brány. (Např. 64bitová latence add je pouze 1 cyklus, 64bitová latence imul je u rodiny Intel Sandybridge pouze 3 cykly. http: // agner. org / optimize /).
Můžete to dokonce navrhnout tak, aby zatížení, které by selhalo (pokud dosáhne důchodu), vůbec nedokončilo provádění a žádný výsledek zatížení není předán závislým instrukcím. Možná dokonce squash, takže neposílá požadavek na paměť v hierarchii směrem k vnějším mezipaměti, pokud nebyl v mezipaměti L1D. (tj. ani to nekontrolujte L1D). Může to být složitější design.
(Některé procesory však takhle fungují, podle testů Henryho Wonga: např. Procesory AMD pro Meltdown vůbec nepřinášejí žádný výsledek. testy oproti některým nezranitelným procesorům, jako je Via Nano produkující nulu nebo Pentium Pro produkující nějakou náhodnou interní hodnotu.)
Tento design by mohl znemožnit (?) procesu v uživatelském prostoru dokonce zjistit, zda adresa jádra byla namapována či nikoli jakýmkoli časovacím útokem, protože mikroarchitektický efekt načtení pouze mapování jádra by byl stejný jako na nezmapované stránce. (Ale ve skutečnosti jen to samé, pokud by také spustilo procházení stránkou. Neschválený přístup TLB by nespustil procházení stránkou a pravděpodobně byste to mohli zjistit přímo.)
To by mohlo být cenné pro zastavit procesy porážející KASLR, pokud jádro použije k mapování své vlastní paměti cokoli menšího než 1G hugepages.
Další informace o vestavbách CPU:
Podrobnosti specifické pro tavení :