Názory k článku
AMD Zen 1-4 nekontrolují správně podpis mikrokódu

Když to tak čtu, vkrádá se mi do mysli otázka: existuje nějaký současný CPU, které nemá chyby, bezpečnostní problémy? Intel, teď AMD, slyšel jsem i o ARMu...

Je to stejné, jako se ptát, jestli dnes existuje software bez chyb. Neexistuje a chyby se bohužel vyskytují i v hardware. Bylo to tak vždycky, i procesor Z80 obsahoval nedokumentované instrukce a chyby a ten měl 8500 tranzistorů. Dnešní moderní procesory mají vyšší miliardy tranzistorů a jsou to stroje složitější o mnoho řádů. Samozřejmě se v nich chyby najdou. Bohužel.

Jsou ale chyby a chyby. Takováto obecná odpověď myslím neřeší otázku, zda je produkt "OK" (pravdou je, že otázka zněla takhle striktně).

10. 2. 2025, 15:40 editováno autorem komentáře

Ale resi.... je potreba si uvedomit, jak slozite ty veci jsou. Coz jde dokreslit i tim, ze na chybu se vubec prislo po ~7 letech (Zen1 je nekdy z roku 2017).

Banální odpovědi všichni známe. Ale otázka by spíš měla znít, jestli to testování probíhá včas a důkladně a za jakých okolností je oprávněné procesor vrátit a chtít kompenzaci.

Není mi jasné, jak to vlastně chtějí (u už vyrobených procesorů) opravit. Pokud vím, update mikrokódu je záměrně navržen tak, aby se musel po každém resetu natáhnout znovu. Existuje vůbec nějaký způsob, jak updatnout mikrokód "na trvalo"?

Mikrokód se do procesoru natahuje při každém startu z firmware základní desky. Čili když se vydá nová verze UEFI pro danou desku, aktualizuje se i „perzistentní“ verze mikrokódu, který pak snad bude moci opravit i tenhle problém a nenechá se nahradit špatně podepsaným mikrokódem za běhu systému.

To ale potvrzujete, že procesor jako takový opravený nebude, jen se problém posune z OS na BIOS (UEFI).

Ono procesor není jenom hardware, ale i software. V CPU je něco čemu se říká microcode.

Princip aktualizace je, že se vytvoří oprava, která se dostane do nové verze BIOSu základní desky.
V rámci zapnutí počítače s novým biosem se zkontroluje, jestli cpu má aktuální verzi microcodu a pokud ne, tak se aktualizuje (tady je chyba, že se nekontroluje podpis).
Teď máme CPU aktualizovaný, ideálně i s opravenou chybou, a pokud se někdo pokusí nahrát novou verzi microcodu, která není podepsaná, tak už to selže

Je to teda tak, ze ak mam dve motherboardy ktore maju rozdielny UEFI. Jeden zaplatany a jeden starsi, tak v nomov sa prvy krat zisti ze CPU ma zastaraly microcode, aktualizuje ho a ak by som ho vybral a vlozil do dosky ktora ma starsiu verziu UEFI, tak bude CPU uz zaplatany?

Ono tam je ve skutecnosti tech procesoru nekolik, natahuje se spousta fw ktery pak dela ruzne veci...

Ona ta chyba totiž asi ani nebude zadrátovaná v CPU, ale je v té SW části.

No on i procesor bez té podepisovací chyby by nebyl bezchybný (někde v diskuzi corebootu jsem kdysi myslím četl, že některé pentium 2/3 mají s mikrokódem od výroby problém vůbec začít bootovat). Proto vůbec něco jako update mikrokódu existuje. Takže se prostě důvěřuje updatu v UEFI (koneckoců stejně se odtamtud načítá i kód pro trénování RAM).

A nebyl to příjemný benefit mikrokódu? Neby za tímto účelem vlastně prosazen?

Treba vymenit CPU za MPU, vsetko co ma vnutornu pamet a algoritmus spracovania instrukcii bude mat bezpecnostne diery.

:-) takže se to opraví nahráním nového mikrokódu?

Podle me jsou mozne dve varianty opravy
- BIOS ktery zakaze runtime microcode loading
- AGESA update, ktery opravi overovani microcode update v PSP

Architektura AMD procesoru je ponekud jinacsi nez Intelu.. resil jsem to nedavno pri ladeni bootu.. ze napr. na Intelu musi bezet prvne x86 jadro a pak to skrze nej ridi trenovani pameti.. zatimco u AMD se po zapnuti nahodi PSP, vytrenuje pamet a az pak se necha pustit jakykoliv x86 kod.

To PSP muze sahat a mluvit tedy do hodne veci.. a divil bych se kdyby podpisy uc updatu resili v hw, kdyz tam maj PSP jadro.

Moznost zakazat updaty nevim zda je pruchozi, na nektere platforme se uc update musi aplikovat pri kazde aktivaci vypnuteho jadra (prechod offline na online).

EDIT: dd/dt by se nemelo automagicky aplikovat, kdyz nejsou ani ve vyctu povolenych znacek dole v napovede!!

10. 2. 2025, 12:53 editováno autorem komentáře

Jaká je praktická zneužitelnost? Když už se někdo dostane do situace, že může nahrát upravený mikrokód, tak má buď:

- write přístup do /lib/firmware a /sys/devices/sys­tem/cpu
- write přístup do obrazu jádra/initram­fs/nastavení zavaděče
- write přístup do distribučních balíčků s výše uvedeným

což je ve všech případech už stejně absolutní prohra a nějakej podpis mikrokódu to nezachrání, protože před i po jeho aplikaci na stroji může útočník udělat úplně všechno.

Pokud se ten modifikovanej mikrokód zapíše do UEFI, tak pak bude děravej jakejkoliv počítač, který bude onu nahackovanou desku používat (takže třeba výhodné pro distributora :-D ).

V čem je to pro útočníka lepší než útočit přímo na UEFI? Napsat payload pro EFI je triviální, jsou na to i tutoriály, nic kromě LLVM nepotřebuju... zatímco mikrokód je daleko náročnější cíl. V čem je teda ta výhoda?

Z informace v článku:
"AMD opravilo mikrokód zatím u CPU EPYC"
Předpokládám že se bavíme o pronájmu virtuálních strojů.
Kde si navzájem nevěří majitel HW a pronajímatel virtuální stanice.

Vy by jste si pronajal HW, který generuje "náhodná" čísla?
Klaiscky jako většina chyb nebude mít vliv na stroje schované za IPv4 NATem.
V případě IPv6 za Firewallem.

10. 2. 2025, 15:25 editováno autorem komentáře

Pokud jako zákazník využívající VM nemůžu důvěřovat provozovateli a jeho hypervizoru, pak je úplně nepodstatné, na jakém HW nebo SW tu VM vlastně provozuje.

Ne tak úplně. Kvůli tomu existují featury jako SEV a celý hype kolem Confidential Computing. A když se podíváte na ten link o opravě pro Epyc, tak asi není úplně náhoda, že nadpis zní AMD SEV Confidential Computing Vulnerability.