Názory k článku
AMD navrhuje systém dynamických záplat na bezpečnostní chyby CPU

> pro servery se pak sluší explicitně dodat, že touto cestou by bylo možné zapínat nové opravy v nových verzích jádra bez nutnosti restartu serveru.

Hmm, jak? Pokud jádro v sobě ten patch nemá, tak jak bude možné jej opatchovat?

Nic takového nepíše ani Phoronix ani autor patche. Mluví se tam o pouze “new settings” pro existující “mitigations”.

Ja bych chtel videt toho (i jednoho) admina libovolnyho serveru, kterej pripusti, ze se mu tam bude neco zachodu menit a on pak bude chodit do kostela i mesity se modlit, ze to minutu potom necrashne ...

ze se mu tam bude neco zachodu menit

Je trochu rozdíl, jestli se to změní, nebo to admin změní :-).

Systémy jsou čím dál složitější.
Takže nad nimi ztrácíme kontrolu.
Každý s různou rychlostí podle jeho schopností.
Takže se může stát že admin něco zapne.
A za chodu se mu tam něco změní pod rukama.

Domyslet a dohledat co vše se změní když za chodu změním parametry CPU je pro mě nereálné.

Ale jestli rozumíte jádru natolik dobře, že se toho nebojíte, tak klobouk dolů.

I kdybys zpameti znal jadro do posledniho bitu, v tomhle pripade menis chovani CPU, a naprosto netusis, jakej vliv to bude mit na bezici jadro, natoz na aplikace.

Osobne mam vsude kde to lze tyhle vopicarny povypinany, a prijde mi jako nehoraznost, ze to bydefult je zaply. Co je horsi, ze se ti to do systemu dostane treba s aktualizaci biosu ... a 30% vykonu v riti. A to ackoli jde treba o jednouzivatelskej system kde bezi jedna aplikace ktera si svy hesla a klice muze cist z disku nebo z ramky a nemusi kvuli tomu hackovat CPU.

Jedinej kdo stimhle ma problem, jsou verejny cmoudy, protoze to je taky jedinej cil, kde se vyplati stravit treba par mesicu lovenim klicu. Ve vsech ostatnich pripadech ... zavolam uzivateli a on mi rekne svoje heslo.

Ve Windows se na úrovni kernelu například přepínání mezi různými implementacemi řeší tak, že máte několik verzí stránky paměti s pointery na funkce, a přimapujete tu která je zrovna potřeba, řekněme s podporou té nebo jiné rozšířené instrukční sady. Pokud jde o změnu funkcionality, tak to je prostý hotpatching. Modifikujete binárku v paměti tak že jí alokujete nějaké další stránky paměti, do nich dáte nový kód, a přepíšete začátek stávajících funkcí tak aby provedly skok na ten nový kód. Těch technik je více, a je to poměrně zajímavá oblast. Například pokud dojde kvůli změně kódu ke změně nějaké datové struktury, tak ji lze při aplikaci hot patche transformovat (stop the world, transform the state). Akorát když vidím jak často se - bez ohledu na platformu - nepovedou ani "klasické" patche, tak bych se v praxi poněkud obával ohledně spolehlivosti.

Konečně!

AMD má pravdu v tom, že nemá cenu mít zapnuté všechny. Pokud mám server někde v clusteru, který mám plně pod kontrolou a nezpracovává nic, co by pod kontrolou nebylo, tak je nejlepší nemít zaplé vůbec nic. Tady se bavíme se o desítkách procent výkonu - to není zanedbatelné.

Mít možnost povypínat to za běhu je jen dobře.

Firma AMD vyřešila problémy intelu.
Nechápu proč to dělají, když to prodlouží použitelnost starých CPU od konkurence.
Možná chtějí ukázat jak to intel dělá špatně.

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

AMD díry jejichž opravy ovlivňují výkon nemá, nebo jak tu poznámku myslíte? Mitigace Inception má v některých serverových workloadech nezanedbatelné výkonnostní dopady (až 50 %) viz https://www.phoronix.com/review/amd-inception-benchmarks/4

Až 50% je v případek kdy se použije SW záplata. Tzv IBPB.
Ale stačí aktualizovat microcode a ztráta výkonu je nepostřehnutelná.

AMD díry jejichž opravy ovlivňují výkon nemá!

Kvůli téhle jedné drobné výjimce fakt nemuseli šahat do kernelu.

Hmm pořád globální settings.
Per process nebo per uid (popř. i per core + affinita) by asi byla lepší, ale řádově složitější...