Názory k článku Jak funguje Spectre a Meltdown, Linux na Orange Pi a změna algoritmu DNSSEC
-
654 (neregistrovaný)
"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?
-
m (neregistrovaný)
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.
-
Není to jen o měření času. Dnešní desky rádi každému prozradí napětí a odběr procesoru. Z těchto údajů lze také odvodit probíhající operaci. Sidekanály přes napětí a odběr kudy leakují privátní klíče jsou běžnou záležitostí a nikdo to nedává za vinu procesoru. Vždy je to chyba kódu, protože lze samozřejmě napsat výpočet tak, aby nic leaknout nemohlo.
Těším se, až se objeví útok využívající čidla na deskách, měření teploty a podobně. Co nastane pak?
Proč se v tomto případě z toho dělá takový problém? Prostě se kód, kde se pracuje s citlivými daty upraví tak, aby útok spectre ani meltdown nebyl možný. Drtivá většina informací v počítači není ekonomicky zajímavá v případě leaku, nebo se nedá jinak využít. Nechápu, proč se tak zuřivě patchuje a zpomaluje globálně.
-
Petr M (neregistrovaný)
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?
"The lack of permission checks for using the clflush
instruction is a weakness of the X86 architecture. Consequently,
the most complete solution to the problem is to
limit the power of the clflush instruction." -
Jiri Kosina (neregistrovaný)
> 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.
-
pc2005 (neregistrovaný)
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.
-
lazywriter (neregistrovaný)
OPI mám (plus 2E), na něm armbian, ale Kodi (distribuční) při startu segfaultuje. Při použití jako miniserver jsem zase narazil na neportovaný multipath.
Takže je tam ještě dost práce. A je to 32bitů. Pro tohle použití to bohatě stačí. Ale jestli se jupíci rozhodnou, že 64bitů je víc adidas, tak kdo ví, jak dlouho bude podporovaný.
