Názory k článku
S opravou chyby AMD Zen 1 při dělení nulou to není tak jednoduché, jak se dříve zdálo

Hodně lidí kritizovali že Win11 nemá podporu ZEN 1. Že to je umělé omezení. Já jsem tvrdil že tam je bug, který nejde opravit.
Trvalo to pár let, ale už mám jasno.

Tak oprava bude, jen to bude mít větší dopad na výkon, než se předpokládalo. A s Win 11 ten bug nemá nic společného. Umělé omezení pořád platí.

Oprava která defakto vypne SMT není oprava ale průkak. Nemůžete vypnout SMT na render stanici kvůli problémů který je zneuzitelny jen při fyzickém přístupu. Protože k render stanici nikdo kromě majitele přístup nemá.

Samozřejmě hodně dobrý hacker se dostane k oprávnění root vzdáleně i na render stanici. A pak by mohl tyto zranitelnosti zneužít. Ale proč by to dělal, když už má práva root.
Problém je jen v případě že pronajmete jedno vlákno. Hacker pak vidí co běží na druhém vláknu.

No, jestli se u téhle chyby nepletu, tím hackerem může být i javascript běžící v browseru, což poněkud mění situaci.

Asi neznate pojem uklizecka a nebo lide z udrzby ze? Co takhle ostraha... ale zijte v dojmu ze vase pc je nedoktnutelne, pac nikdo jiny k nemu nemuze.

Jasně! MS ten bug zjistil hned za 1 minutu testování, díky tomu nedal podporu pro Zen 1 do Windows, a všechno si to nechal jen pro sebe!

Možná by to chtělo místo bezhlavého psaní na rootu začít trochu přemýšlet o tom co píšu.

15. 8. 2023, 08:33 editováno autorem komentáře

Samotná šéfka AMD Lisa Su se k tomu vyjadřovala.
M$ je vyzval na spolupráci při podpoře.
A sami museli uznat že to nejde.
Vzhledem k tomu že Win11 normálně naběhne.
Tak to je skoro jistě bezpečnostní problém.
A věděli o něm už dávno. Jinak by ho neopravili v ZEN 2.

V tom pripade by to nesmelo podporovat zadny Intel.

Sranda jak v minulé diskuzi převládá názor, že to jde opravit v aplikaci. To ale útočníka vůbec nezajímá. Ten si napíše aplikaci, která dělit nulou bude. Pro pronájem virtuálních serverů to je noční můra. Ty musí vypnout SMT.

A tak zrovna maximalne sestnactijadro s TDP 180W neni pro pronajem virtualnich serveru zadna hitparada. Cilovka byly navic desktopy a pokud si na tom nekdo stavel serverove sluzby... no myslim, ze koupit neco novejsiho se vyplati uz jen kvuli te spotrebe... :-)

Postižen je i EPYC 7001.
7501 až 7601 má 32 jader a měl 64 threadů.

Toto má líp vyřešené ARM - při dělení 0 je výsledek 0 - jednoduché, nezneužitelné.

Super, takze namiesto toho aby sa korektne vyhodila nejaka chyba tak isto ako sa deje v matematike - je to nedefinovany stav. Tak sa radsej vyhodi konkretne cislo - 0. Preco sa nevyhodi Int32.Min, alebo Max, alebo Int64.Min, alebo Max? Su v ARMe skryte dalsie taketo matematicke omyly s ktorymi treba ratat pri pisani kodu?

To je ale úplně jedno. Z hlediska moderního návrhu CPU je nejlepší minimalizovat výjimky tohoto typu. FPU exceptions už taky nikdo nepoužívá, protože tu máme SIMD, maskování a další věci...

Pokud dělám VM, tak ta podmínka tam stejně musí být, protože odchytávat signál kvůli dělení nikdo nechce. A pokud používám jazyk jako C, kde to bude undefined behavior, tak stačí použít sanitizer nebo do kódu přidat assert.

V CPU tuto funkci prostě už nikdo nepotřebuje, je to naprosto zbytečné.

Takze o tom, co dela CPU a SW nemas paru ze? Ono se totiz na deleni nulo muze snadno dojit ... delenim nenulou. Jednoduse proto, ze nekde neco pretece. A ten tvuj uplne neskodnej vysledek ... tedy nula = vse bezi dal, jen nekde neco (treba jaderna elektrarna) vybuchne.

A vazeni, presne takto dnes vypadaji ti, co se zovou programatory. Vubec netusi co cini.

Jako že v jaderné elektrárně se budou spoláhat na to, že CPU zachytí integer division by zero? CPU vygeneruje exception, a co pak? Mohl bys to tu rozepsat, když tomu tak rozumíš?

Nevim kolik toho v životě udělals ty, ale já ti garantuju, že zrovna u těchto věcí ty kontroly budou úplně všude a k tomu dělení nulou nikdy nedojde právě kvůli tomu, že ty hodnoty budou zkontrolované 10x, a obě!

Dělení 0 je undefined behavior - žádný C/C++ kód se nemůže spoléhat na to, co CPU udělá, protože každá architektura má vlastní chování. Portabilní kód si vstupy prostě musí kontrolovat a ne čekat na to, že CPU něco udělá v takovém případě. Ve většině SW když k tomuto dojde, tak ten proces končí.

Jedno to teda rozhodne neni.

Ak si vrstva podomnou (to jest HW) stvara psie kusy o ktorych ja nemam paru pretoze logicky ocakavam nieco ine (tu to bude exception), rovnako ako to ocakava 99.999% programatorov.
To ze niekto bol lenivy to urobit naporiadok aj ked komplikovane, a rozhodol sa s tym radsej vym**at tym ze vrati nezmysel (tu je to ta nula), tak to urcite nie som nadseny z takej architektury.

To sme opet v dobe kedy napr intel mal FDIV bug, ked vracal pri deleni floatov zle vysledky (resp prvych par cislic bolo spravnych ale potom presnost vysledku isla do kopru).
Az z toho vznikol vtedy vtip:
Je sutaz kde dva procesory, Intel a AMD sutazia kto je lepsi. Rozhodca povie otazku - kolko je 2+2?
Intel v tom okamihu bleskurychle zahlasi 5. AMD o moment neskor odveti 4, a nasledne hovori intelu - vies ze 2+2 ma byt 4 a nie 5, tvoja odpoved je nespravna. Intel odveti: To je mozno pravda ze som povedal zly vysledok, ale ta rychlost!
No, a ak takto vyzera ten preslaveny ARM, tak to nie dakujem, zostanem radsej u X86/64.

Mám pocit, že hodně lidí v této diskuzi nechápe rozdíl mezi HW a programovacím jazykem. Pokud používáš C++, tak dělení nulou je UB. Pokud jiný jazyk, který tu operaci specifikuje, tak se můžeš spolehnout na kontroly, které tam přidá compiler toho jazyka.

Tím bych tu diskuzi ukončil, nemám čas se hádat s lidma, co toto nechápou a navíc tu řešit nějaké hloupé paralely s jinou chybou, která s tímto vůbec nesouvisí.

BTW jen pro doplnění: ARM a RISC-V jdou úplně stejnou cestou, doporučil bych si o tom něco přečíst.

Nastesti matematika a IT jsou dva oddelene svety.
Co je matematicky spravne nemusi byt v IT optimalni a naopak.
Tohle by mel nekdo studentum vysvetlit uz na zacatku studia jinak ta hovna budou tahat cely zivot do kodu.

Musim se smat ... jak mi bylo u minule novinky tlaceno, ze ta "oprava" to resi, kdyz uz tam bylo zjevne, ze i autor patche vi, ze neresi.

Petkov ten druhý patch poslal až v pátek 11. 8. a nějakou dobu trvá, než si toho někdo všimne. Ale stejně naše zprávička vyšla 10. 8., tak nevím, na co si stěžujete.

V tom patchi bylo NAPSANO, ze chybu neresi, hlasil do logu, ze je treba vypnout SMT.

Že chybu neřeší tam teda není, je tam napsáno: "AMD Zen1 DIV0 bug detected. Disable SMT for full protection."