Vlákno názorů k článku
Zranitelnost podobná Meltdownu objevená v procesorech s architekturou ZEN
od David Ježek - Vida, tak uvidíme, jak se AMD fans budou...
-
kdyžtak "nejhorlivější", pane kolego :-). Ale k věci: ano, poslední 3 roky vídáme v diskusích příspěvky o tom, kterak sice Spectre mají oba, ale AMD aspoň nemá Meltdown, protože [dosaďte libovolný důvod]. Tak jsem zvědav, jestli se rétorika nějak změní. To vše nezávisle na tom, jestli nyní jedu osobně na Intelu, nebo jsem v minulosti jel spokojeně na AMD (mimochodem: 486 DX4, K6-233, Duron 1200, Duron 1800, Athlon 3000+, Athlon 64 3200+, Athlon 64 X2 4400+, Athlon 64 X2 BE).
-
Pokud nesledujete CVE, tak můžete skutečně mít takový dojem protože o chybách v procesorech Intelu se mluví a o chybách v procesorech AMD nikoliv. Ve skutečnosti jsou na tom v poslední době zhruba stejně.
Příkladem nechť bude tato perla se severity 9: CVE-2020-12967 o které nikdo neví (je pravda relevantní pouze na serverech s hypervizorem).
Nebo "I See Dead μops" o které se sice psalo v souvislosti s Intelem i AMD... ale když se později ukázalo, že na Intelu dodatečné mitigace nejsou potřeba a na AMD ano, tak o tom už pak nepsal nikdo páč to není zajímavé.
-
Peter FodrekZlatý podporovatel
úplne ako doteraz Korigovať nepresnosti. Je to priekak,ak by existovalo jedine riešenie pomocou LFNECE.
AMD recommends that SW vendors analyze their code for any potential vulnerabilities related to this type of transient execution. Potential vulnerabilities can be addressed by inserting an LFENCE or using existing speculation mitigation techniques as described in [2].
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1010Našťastie existuje aj iné riešenie. Použite LFENCE všade sme si otestovali v patchi SESES
Google Engineer Shows "SESES" For Mitigating LVI + Side-Channel Attacks - Code Runs ~7% Original Speed
on 21 March 2020
peculative Execution Side Effect Suppression (SESES) and was started for mitigating Load Value Injection but expanded to address other side-channel vulnerabilities like Spectre V1/V4 and others. It offers extra safeguards beyond just LVI mitigation, but in Google's own BoringSSL test (their fork of OpenSSL), the performance came in to a 7% geometric mean of the original performance (not a 7% hit, merely 7% the original performance).
https://www.phoronix.com/scan.php?page=news_item&px=LLVM-SESES-Mitigating-LVI-More -
Peter FodrekZlatý podporovatel
Je tu ešte jeden rozdiel.
V prípade Meltdown Intelu (a Spectre na oboach)treba mať kód s viac ako 10-bitovovou adresou. (útočiaci program zaberá viac ako 1MiB virtuálnej pamäte, aby dokázal vytiahnuť všetky dáta zo systému )
V tomto prípade pre AMD treba mať kód s viac ako 48-bitovovou adresou (útočiaci program zaberá viac ako 256 TiB virtuálnej pamäte, aby dokázal vytiahnuť všetky dáta zo systému bez ohľadu na cieľ útoku) -
Peter FodrekZlatý podporovatel
napr. Prediktory, ktoré sa zneužívajú pri Meltdovn-e používajú spodných 20 bitov virtuálnej adresy (omylom som napísal 10 bitov.)
Teda Adresy
binárne
00 000 000 000
10 000 000 000
100 000 000 000
101 000 000 000
....sú pre prediktor identickou Adresou 0 000 000 000
ako aj
00 000 000 101
10 000 000 101
100 000 000 101
101 000 000 101
......sú pre prediktor identickou Adresou 0 000 000 101 a teda si kódy na všetkých uvedených adresách vo všetkých kódoch na systéme vvzájomne ovplyvňujú prediktory. = a to od spustenia PC
(Vsuvka:Preto úspešnosť predpovede je skoro náhodná aj keď je deterministická
It Turns Out CPU Speculative Execution Can Be Useful For Random Entropy / RNG
29 September 2019
Particularly on newer Intel/AMD CPU microarchitectures where speculative execution is much more advanced than hardware from years ago, it's been found that measuring the execution time of loops relying upon speculation is random enough to be a cheap and speedy source of entropy.
https://www.phoronix.com/scan.php?page=news_item&px=CPU-Spec-Exec-RNG-Entropy
)teda na ovplyvnenie ľubovoľného prediktora v ľoibovoľno kóde, aby bolo možné prečítať nejaké dáta z iného procesu treba skúsiť
2^20 = 1 048 576 možností pre každý prediktor
Tu sa zneužíva to, že sa kontroluje len spodných 48 bitov vituálnej adresy včas.
1 000 000 000 000 000 000 000 000 000 000 000 000
teda na ovplyvnenie ľubovoľného prediktora v ľoibovoľno kóde, aby bolo možné prečítať nejaké dáta z iného procesu treba skúsiť
2^48 = 2.81 *10^14 možností pre každý prediktor
Ono to je asi dôvod prečo sa na to prišlo v prípade AMD o toľko neskôr
ako v prípade Intelu. -
SinuhetStříbrný podporovatel
Já teda nevím, co máte na mysli, ale pokud 48 bit adresa znamená 256 TiB, pak 10 bit adresa bude 1 kiB.
-
Ondra Satai NekolaZlatý podporovatelMelo by se to tykat vic CPU, nez je v originalnim paperu:
https://www.tomshardware.com/news/zen2-processor-vulnerability-mitigation
-
Můžu posloužit například zlehčováním problému :-)
"Crucially, their technique cannot be used by one process to read the memory of another process or of the kernel; instead, it can be used by one thread in a program to affect another thread in the same virtual memory space. In other words, it's not as straight forward as a classic Meltdown attack in which, say, a rogue application siphons off keys from kernel memory."
