Vlákno názorů k článku Nový vývoj kolem Spectre a Meltdown a naštvaný Linus Torvalds od Ondřej Novák - Mně se to nelíbí, ale myslím tím mediální...
-
Mně se to nelíbí, ale myslím tím mediální humbuk, včetně Rootu. Místo vysvětlení o co jde jen shrnutí mediálního odpadu z celého světa a nic z toho.
Já si vůbec nejsem jist, jestli je chyba u výrobců procesorů. Co když tím, kdo má máslo na hlavě je Linus a obecně vývojáři operačních systému? Spekulativní exekuce je rys CPU, nikoliv chyba! Že si vývojáři nevšimli, že existuje možnost side kanálu? Ať to koukají napravit! Že je Linux blbě navržený z hlediska organizace kernel vs userspace? Ví se to už dlouho, nekonečné diskuze na téma, proč se ani ve třetím tisíciletí neprosadili mikrokernelové OS. Tam kde je kernel plně oddělen od procesu, tam se nechytá aní Spectre ani Meltdown.
Dejme tomu, že Meltdown je problém, který by nakonec Intel mohl fixnout na své straně. To jak se vývojáři snaží co nejrychleji opatchovat Spectre se mi vůbec nelíbí. Tvrdím, že tenhle bug se týká jen omezeného množství programů, tam kde existuje přímá komunikace mezi procesy na úrovni sdílené paměti. Že lze javascriptem přečíst obsah celého procesu, ve kterém běží? No od čeho je sandboxing že? Že v novinách psali, že je přes Spectre možné utéct ze sandboxu? Nevěřte všemu, je to odpad. Nejde!
Spectre není bug, je to rys procesoru. Je to asi tak jako že měřením odběru proudu lze odhadnout, co počítač dělá. Jo, když to je zařízení typu Bitcoin Trezor, tak je to průser, protože lze odvodit privátní klíč nebo seed. Tam se kód musí psát speciálně, aby každá operace brala stejné množství proudu. Ale domnívám se, že 99% všech uživatelů PC tímto útokem postiženo není. Tam kde jde o kritické funkce, tam si to vývojáři fixnou. Globální patchování bude působit medvědí službu.
Až humbuk utichne, vyjdou úpravy jader a patche takové, které se nijak na výkonu neprojeví. Určitě se objeví snahy jak navrhnout OS jinak, tak aby byl odolný proti případným side kanálům způsobených spekulativní exekucí. Zároveň bude stejně rychlý jako jeho předchůdce. Vývojáři se to naučí psát dobře. Kód náchylný ke Spectre útoku se zařadí po boku jiných chyby jako třeba buffer overrun.
Spekulativní exekuce tu zůstane i nadále v nezměněné (v případě Intelu mírně pozměněné) verzi.
-
PetrM (neregistrovaný)
Linux nenaprogramoval Linus, ale pěkně dlouhá řada lidí a firem. Linux totiž funguje tak, že libovolnou jeho část můžeš použít ve svým produktu výměnou za zveřejnění úprav. Schválně, zkus si na zdrojáky jádra poštvat git blame, jestli je všude Linus. A grepni si výsledky na @intel.com, jestli tam není i někdo s informacema z první ruky.
A v praxi jsem se už hodněkrát setkal s tím, že v dokumentaci bylo něco úplně jinýho, než co ten křemík fyzicky dělal. On totiž někdo jiný navrhuje logiku obvodu, někdo jiný z toho kreslí masky pro křemík, někdo jiný to dokumentuje, další chystá testy a někdo úplně jiný to testuje. Stačí nějakou "blbinu" špatně pochopit nebo špatně vyhodnotit výsledek testu... Třeba u Atmelu mě to už stálo pěkných pár měsíců života (a díky tomu jsou Atmelí brouci na blacklistu, s nima bych si nevydělal ani na slanou vodu).
-
MarSik (neregistrovaný)
To je samozřejmě pravda. Ale Intel je velká firma a ne všichni se zabývají kernelem na úrovni MMU, TLB a cache. Takže je otázka, kdo přesně psal tu nízkoúrovňovou část a jestli nezapomněl na nějaký malý detail zmíněný v datasheetu. Vzhledem k tomu, že ten detail by nejspíše ovlivnil celkovou architekturu jádra to může být klidně důsledek dávného rozhodnutí udělaného samotným Linusem (mapování fyzické paměti do adresového prostoru kernelu a tím potažmo každého uživatelského procesu).
Z mé zkušenosti je běžné zapomenout na nějakou maličkost i u třeba Cortex M0+ implementací. A to je řádově (hodně řádů) jednodušší procesor / mikrokontroler. I tak má třeba MKE04P24M48SF0RM více jak 600 stran. Tiva C (Cortex-M4) už jich má 1400. Intel i7 bude určitě složitější..
Takže Ondřej má pravdu v tom, že to celé může být považováno za vlastnost a starost programátorů OS. Jenže na druhou stranu se architektura OS na této úrovni dost těžko mění ze dne na den.. takže nemuselo být už možné to elegantně obejít. Obzvláště, když to doteď nikoho nenapadlo a Linux je dnes pekelně složitý systém.
-
Martin DrábStříbrný podporovatel
> Takže Ondřej má pravdu v tom, že to celé
> může být považováno za vlastnostV případě Spectre bych i souhlasil (nepřímo čtu paměť, na jejíž čtení mám dle procesoru právo). U Meltdownu je ale problém v tom, že se dostanu ke stránkám, které mají nastavený bit U/S tak, aby je číst z uživatelského režimu nešlo. Pak takový bit ale celkem postrádá smysl. Myslím, že v manuálech jsem nikde neviděl deklarovanou nutnost vymazat TLB při návratu do uživatelského režimu.
Stejně by mě zajímalo, jak se tím Meltdownem dá dumpnout celá fyzická paměť, která je namapovaná ve virtuální. Protože přecejen ne všechna je odkazována v TLB a ne všechnu dokážu do TLB z uživatelského režimu "dostat".
-
MarSik (neregistrovaný)
Jak chápu Meltdown tak to je prostě spekulativní přístup do pole s pomocí neznámého indexu, který skončí v cache a Flush + Reload dává možnost zjistit, která položka pole v cache skončila, čímž zpřístupní tu neznámou hodnotu. Takže se nedostanete ke stránkám, ale k jednotlivým bytům / wordům. Větší bloky asi už nejsou reálné, kvůli velikost toho pole pro cache. Ale i tohle asi stačí s vhodným cyklem (Meltdown paper mluví o rychlosti získávání data řádově ve stovkách KB/s)
Kernel má namapovanou kompletně celou fyzickou RAM:
For a 64 bit Linux the kernel logical range lays from 0xFFFF880000000000 to 0xFFFFC7FFFFFFFFFF
where you have a direct mapping of all physical memory. Moreover, 512MB of physical memory starting at
0x0 are also mapped to the logical range 0xFFFFFFFF80000000--0xFFFFFFFF9FFFFFFF (kernel text
mapping). The memory mapping for the 64 bit kernel is described in details in the kernel documentation
under Documentation/x86/x86_64_mm.txt. -
Martin DrábStříbrný podporovatel
> Jak chápu Meltdown tak to je prostě
> spekulativní přístup do pole s pomocí
> neznámého indexu, který skončí v cacheNe, jedná se o spekulativní přístup na adresu, jejíž stránka je chráněná bitem U/S před čtením z uživatelského režimu. Pole tam pravděpodobně vidíte proto, že mnohé exploity jej tam používají pro zmatení branch predictoru.
Ano, v Meltdown whitepaperu píší, že Linuxy mapují celou RAM. Moje otázka byla, jak to mapování postupně dostat do TLB, protože jinak se ten spekulativní přístup nekoná (alespoň to mám vyzkoušené na Spectre, na Meltdown ještě ne). Protože bez TLB ten přístup bude trvat o hodně, hodně déle (je třeba provést přístupy do čtyř úrovní stránkovacích tabulek).
-
MarSik (neregistrovaný)
To pole (probe_array) se nepoužívá pro zmatení branch prediktoru, ale pro zjištění hodnoty na té adrese. Protože přímo z cache tu hodnotu nevyčtete. Dá se to ale nepřímo pomocí zjištění, která stránka skončila v cache po provedení probe_array[4096 * (*adresa)]. Koukněte na Listing 1 (a 2 pro ASM verzi) v tom paperu. Figure 4 potom ukazuje, že prostá iterace přes probe_array (kam máte přístup) stačí ke zjištění neznámé hodnoty, protože ta jedna použitá stránka z cache je rozpoznatelná podle rychlosti přístupu k ní.
Ty adresy pro mapování paměti nemám z Meltdown paperu, ale z prezentace pro debugging Linuxového kernelu. Samotná dokumentace kernelu říká:
4 level TLB:
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memoryTakže bych řekl, že to už namapováno je a MMU to bez otázek přeloží. Urychlení může spočívat čistě v tom, že tu paměť přečtete sekvenčně. Meltdown paper tvrdí, že rychlost čtení je méně než jeden MBps. To není zrovna závratná rychlost.
-
Martin DrábStříbrný podporovatel
Ano, s těmi poli jsem to zval za špatný konec. Co se týče probe_array, viděl bych jej spíš jako součást Flush&Reload útoku. Meltdown zde přidává čtení z té nepřístupné adresy (ve vašem příspěvku *adresa). Kdyby při spekulativním vykonávání instrukcí docházelo i ke kontrolue U/S bitu, tak není co řešit. Proto se nejedná o vlastnost.
> fyzická paměť
Pořád se mi nezdá, že by se tohle mapování přímo vešlo do TLB, (cache) které bude mít místo jen na cca pár stovek překladů. Že ve stránkovací tabulce bude nějaké takovéto přímé mapování, s tím nemám problém.
> Meltdown paper tvrdí, že rychlost čtení je
> méně než jeden MBps. To není zrovna
> závratná rychlost.To může ukazovat na množství operací, které je třeba provést, aby byla určitá jednotka paměti přečtena s dostatečnou spolehlivostí (obsluha výjimek, měření časování atd.).
-
MarSik (neregistrovaný)
Ano Flush & Reload je součástí Meltdown.
Při spekulativním vykonávání se příznaky nekontrolují a je to podle všeho známá vlastnost. On totiž kód může obsahovat něco jako if (root) { *(0x0) = 1 }. Spekulativně vykonaná then sekce pro non-root uživatele by musela umožnit normální provedení else větve, i když by selhala. x86 je už tak dost složitá, tohle by ještě přidalo... ale asi to v budoucnu nějak tak stejně dopadne.
Ono se to přece do TLB naráz vejít nemusí. Čte se to byte po bytu. Prostě to bude jen pomalejší. TLB si MMU spravuje sama, jestli si to pamatuju správně, tak není problém s tím, že se musí občas mapování zahodit a vložit nové.
-
Martin DrábStříbrný podporovatel
> if (root) { *(0x0) = 1 }.
Vzhledem k tomu, že do Ring 0 se dnešní OS (už velmi dlouho) dostávají skrz instrukce syscall/sysenter, popř. softwarovým přerušením, podle mě by opravdu nevadilo, kdyby si procesor někde pamatoval příznak, v jakém režimu běží, a to takovým způsobem, že by jej bylo možné použít i při spekulativním vykonávání instrukcí (jelikož jej není třeba často aktualizovat).
> TLB
Ano, spravuje jej zejména MMU (a trochu OS, když mění stránkovací tabulky). Můj point byl ten, že kódy, které jsem viděl, obvykle předtím, než provedou Meltdown, se příslušné paměti dotknou (např. vhodným systémovým voláním), než "spustí maškarádu". Takže mají v podstatě jistotu, že potřebný překlad v TLB bude. Ale tímhle způsobem se nedá dostat k celé namapované fyzické paměti (nějak deterministicky).
Ale možná, že při (nespekulativním) přístupu na kernelovou adresu procesor TLB mění, kdežto při spekulativním vykonávání přístupu na adresu, na kterou oprávnění má (můj test), se nic do TLB nepřidává.
-
lopata (neregistrovaný)
Prosím nešiř tady bludy a nepiš o věcech, kterým nerozumíš. Spectre lze využít k přečtení dat jiných procesů a tedy i k úniku ze sandboxu. Už jsem ti jednou psal jak: https://www.root.cz/zpravicky/patche-kernelu-a-gcc-opravuji-spectre-a-meltdown/954299/. Potvrzuje to i spectre paper: https://spectreattack.com/spectre.pdf
More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation
Prosím nastuduj si to předtím, než se k nečemu začneš vyjadřovat.
-
. . (neregistrovaný)
tahle otázka se řeší/řešila, viděl jsem kdysi i nějaké poznámky od Intelu v datasheetu, spekulativně se provede cokoliv, ale výsledek se použiji až po kontrole. Trik, že se k výsledku dá dopracovat vedlejšími kanály je pro mě překvapením, nejsem v tom sám.
Chyby přiznalo i IBM u Poweru, zatím pouze intel má dvojchybu a k výsledku se dá snadno dopracovat, je ale asi otázka času dokud se podobná chyba nenajde i jinde
ČLÁNKY DO MAILU