Vlákno názorů k článku Jak funguje Spectre a Meltdown, Linux na Orange Pi a změna algoritmu DNSSEC od 654 - "Poté pomocí měření rychlosti přístupu do paměti zjistí,...

"Poté pomocí měření rychlosti přístupu do paměti zjistí, která stránka byla načtena"

V tomhle je ten největší pr*ser. Nejde ani tak o to že je možné, ale že se o tom ví minimálně od roku 2013 (nejstarší studie, kterou jsem o tom našel - https://eprint.iacr.org/2013/448.pdf) a nic moc se s tím nedělalo, i když byly poté provedeny úspěšné "laboratorní" útoky na šifrovací klíč programu PGP, a to i skrz virtuální OS. Mimochodem tato studie navrhovala i rozhození časovače, aby nebylo možné přesně měřit čas přístupu do paměti, takže toto částečné řešení není žádná novinka. Neřešilo se to, protože neexistoval spolehlivě proveditelný útok v reálném provozu. Teda dokud někdo nepřišel s nápadem využít spekulativní spouštění a branch prediction k přesnému zacílení. Není možné opravit chybu architektury procesoru za půl roku, v tom mají Intel a AMD pravdu, ale 5 let už by mělo stačit aspoň na návrh řešení, ne?

problem je ze intel to zacal resit az loni na podzim kdy si uvedomili o jak velky pruser jde.

A ted prichazi ta sranda .. vyvoj procesoru trva 3-5 let, ale vetsi hacek je v tom ze opravit prediktory a zachazeni s cache aby nepoustela informace co nema a pritom vse zustalo zpetne kompaktibilni a zaroven to nevzalo moc vykonu kremiku je skoro nemozne.

Mam dojem ze tie senzory na doskach niesu zdaleka tak presne, aby ti mohli byt k niecomu platne. Navyse nedavaju k dispozicii okamzitu hodnotu. Presnejsie udaje dostanes ked si k meracim bodom pripojis osciloskop.

No senzory a měření napájení... Připojeno po SMB@400kHz (standard), vyčtení jedné 16b hodnoty je na přenos pěti bytů, každý 10 taktů. 400k/50 = 8kSps pro jednu hodnotu.

Procesor maká třeba na 3GHz, jeden vzorek máš teoreticky až 375M instrukcí (pokud počítám plnou pipeline a 1 takt/instrukci). Navíc teplota a napájení se sdílí třeba pro osm jader a na každým jede něco jinýho... Pokud z toho přečteč konkrétní stránku, kterou se zabývá konkrétní proces na konkrétním jádře třeba jenom 20us pod 95% chyb, tak seš fakt dobrej.

> Navrhují také zakázat instrukci flushování v usercode. Což mi přijde jako rozumná věc. Proč vlastně je clflush
> povolená na user ringu?

Obavam se, ze to by nic nevyresilo. Naimplementovat si neprivilegovany clflush (tim, ze se vytvori explicitni tlak na vsechny cachelines) je docela snadne.

V kernel-only ringu ti je clflush prakticky k ničemu. Hodí se ve chvíli když chceš říct procesoru, že tyhle data už nebudeš potřebovat a tak je může začít vracet do vyššího levelu cache a řádku může použít jiné vlákno. Bez zavolání clflush by procesor nevěděl zda brzy nebudou ty data zase potřeba (například load "za horizontem" fronty instrukcí) a tak by je nechal v dané cacheline (například do doby, než by pro tu cacheline přístup pro jinou adresu). Takže díky vhodně umístěném clflush ušetříš třeba 200 taktů kdy procesor stojí a čeká na ukládání do RAM.

Je to víceméně ekvivalent "fstrim" pro SSD.

V kernelu ti je clflush k ničemu, protože tam se nezpracovávají velké bloky dat. Clflush ukládá 1 řádek, což je 64 (nebo 128) bajtů.

BTW "the most complete solution" je zrušení prediktorů (kódu a přístupu do paměti, clflush je toho součástí), což ti výkonnostně vrátí procesor skoro do té doby kdy to bylo zavedeno.