Zranitelnost podobná Meltdownu objevená v procesorech s architekturou ZEN

Vida, tak uvidíme, jak se AMD fans budou projevovat v diskusích nyní :-).

A vida, kdo byl nejhorčejší si plivnout na AMD a jejich fanoušky...Nejspíš už mu lezlo krkem, že se pořád a pořád a pořád psalo jen o chybách Intelu.

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 si dobře pamatuju, tak tu nejde o nějaké 2 (nejznámější) zranitelnosti - Intel jich má tolik dalších, že už to AMD asi nikdy nedožene, takže s tím ukončováním kopání do Intelu bych moc nespěchal.

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é.

ú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-1010

https://developer.amd.com/wp-content/resources/90343-D_SoftwareTechniquesforManagingSpeculation_WP_9-20Update_R2.pdf

Našť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

[David Ježek]

Zprava me opravdu nepotesila, jsi ted spokojen?

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)

Můžete to prosím rozvinout? Co znamená program s deseti či 48 bitovou adresou?

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.

Spíš je to prkotina.. protože musíš mít přístup od správce na OS... takže tadle díra je celkum zbytečně nafukovaná :))

Já teda nevím, co máte na mysli, ale pokud 48 bit adresa znamená 256 TiB, pak 10 bit adresa bude 1 kiB.

nejak mi to nevychádza,... tým myslím jeho divný výpočet a netuším kde nabral práve tie TiB.

2. 9. 2021, 13:33 editováno autorem komentáře

10 bit - ki
20 bit -Mi
30 bit -Gi
40 bit -Ti

2 bit =256

To je samozrejme preklep Išlo o 20 bitovú adresu

Jediny AMD co mam je Epyc 1st gen, ale o nem neni zminka v paperu, zacinaj na Zen+ a Epyc 2nd gen.

Melo 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."

Není náhodou na rootu moderace diskuze, aby se tady neobjevovaly přesně tyhle zbytečné komentáře?

Názory nesmí obsahovat:
...
Texty, které mají za cíl jen vyprovokovat emotivní reakci (trolling).

Upřesnil jsem svoji pointu výše v reakci. Jestli v tom chcete spatřovat trolling, já těžko mohu ovlivnit.

Jasně že to je trolling. A od člověka, který na Rootu působí jako aktivní autor, je takový projev v diskusi mírně řečeno hloupý.

Nepsal nahodou Zhouba Stach, ze Meltdown vznikl kvuli nepoctivemu a uspechanemu navrhu Intelu, ktery v podstate doufal, ze se na to neprijde? Jsem zvedavy, jak tohle vysvetli. Budto je to oproti Meltdownu prece prkotina, tak zduvodnil Spectre u AMD, nebo za to stejne muze Intel.

Na tom nezáleží, protože každý si najde svou hůl, kterou se bude ohánět okolo sebe. Nezáleží kdo, nakonec se vytvoří dav a jak se říká, v davu logiku nehledej. Vlastně ani nezáleží na tématu, procesor, disky, nebo covid.

Reknou ze to maj cross-licensing a opsali to z Intelovho zabugovaneho patentu.
Kdyz opisujete, nemuzete vedet, zda to chytrolin od vedle ma spravne :-)

To je zase další "chyba", kde u AMD jsou třeba administrátorský práva? Protože AMD narozdíl od Intelu má jinou, bezpečnější konstrukci. K čemu by tedy byla chyba, když je třeba root? :D Intel vědomě kvůli výkonu nezahrnul základní bezpečnostní prvky jen kvůli výkonu. Intel je bezpečnostní díra sama o sobě, dokáže to hacknout skoro každý díky fatální, vědomé chybě v architektuře. AMD takovou vadnou architekturu nemá. Intel, kdyby fungoval trh a nebyl zkorumpovaný, nesměl by do prodeje.

Tato zpráva je jen výkřik, to není ani zpráva.