Názory k článku
AMD Zen5 má problém s RDSEED
-
Jak muze jadro zakazat instrukci?
Spis vyvojari jadra se rozhodli ze ji pouzivat nebudou, a to je neco jineho prece.
A aplikace, ktera pouziva rozsireni instrukci sady, bez toho, aniz by si zkontrolovala zda muze (skrze cpuid flagy), je trocha naprd.. ale to je naprd i u libc, holt to jsou strelci ... namisto normalni hlasky ze mate starej komp pak lustite segfault/kernel panic na invalid opcode :D
-
Az na to, ze nelze overit zda si to vycucal pro tve uspokojeni, nebo k tomu ma i referenci na zdroj.
https://www.phoronix.com/news/RDSEED-Disable-All-Zen-5
https://lore.kernel.org/lkml/20251018024010.4112396-1-gourry@gourry.net/obsahuje prave jen mazani CPUID flagu pres backdoor skrze MSR:
static void init_amd_zen5(struct cpuinfo_x86 *c) { + /* Disable RDSEED on AMD Turin because of an error. */ + clear_cpu_cap(c, X86_FEATURE_RDSEED); + msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18); + pr_emerg("RDSEED is not reliable on this platform; disabling.\n"); } -
na 99% jsem si jistej, te si to vycucal z prstu (neslo by malicko prodlouzit edit puvodniho postu? ty referencni pdfka za tu chvili fakt nejde projit, ja vim, prvne cti, pak postuj...) za coz se omlouvam,
Edit na 100%. Davam si do workflow krome "please provide direct references" i "please verify this claim in provided reference" Ach jo, tohle se v nasem ustavu stava nejvyse jednou za 10 let...
7. 11. 2025, 21:59 editováno autorem komentáře
-
Sorry, ne. Jen tenhle víkend mi to udělalo nejméně čtyřikrát, že to nějaké referenční PDF (nebo v dalších případech konkrétní zákony) prošlo, jednou (tady) jsem ze sebe udělal blbce že jsem to nezkontroloval předem, a třikrát musel explicitně v tom dokumentu najít, že to tam vůbec není, a explicitně mu to napsat, aby konečně vypadlo, že nemá pravdu.
Je to výborné coby vyhledávač, kde to dokáže něco rychle najít mezi mraky odpadu (jo konkrétní crash nějakého modu ve hře to dokáže profiltrovat), ale ani na prohledání (nebo shrnutí) dokumentu se nedá spolehnout, pokud si člověk nenechá explicitně vypsat konkrétní body nebo citace, a neověří si je proti samotnému zdroji..
-
Já bych tomu i věřil. K čemu by bylo povolený rdseed bez oznámení podpory v cpuid?
Koukal jsem se kde se všude v kernelu ta clear bit funkce používá a:
/*
* Bit 15 of Athlon specific MSR 15, needs to be 0
* to enable SSE on Palomino/Morgan/Barton CPU's.
* If the BIOS didn't enable it already, enable it here.
*/
if (c->x86_model >= 6 && c->x86_model <= 10) {
if (!cpu_has(c, X86_FEATURE_XMM)) {
pr_info("Enabling disabled K7/SSE Support.\n");
msr_clear_bit(MSR_K7_HWCR, 15);
set_cpu_cap(c, X86_FEATURE_XMM);
}
}Koneckonců dokud kernel nepřepne z reálnýho módu do 32bit nebo 64bit, tak se taky nemůže použít spoustu instrukcí ;-). Hmm teďka nevím, nenastavovala se podpora VT-x v dobách core2duo v BIOSu, aby se pak dala v OS vůbec použít?
-
Fakt je to jen halucinace, a to jsem stahoval nejnovější 6.18rcnevim, abych se do toho msr-index.h podíval. Ano, mohlo by to tam být, ale není. Ani v skoro 800stránkovém PDF od AMD.
/* EFER bits: */
#define _EFER_SCE 0 /* SYSCALL/SYSRET */
#define _EFER_LME 8 /* Long mode enable */
#define _EFER_LMA 10 /* Long mode active (read-only) */
#define _EFER_NX 11 /* No execute enable */
#define _EFER_SVME 12 /* Enable virtualization */
#define _EFER_LMSLE 13 /* Long Mode Segment Limit Enable */
#define _EFER_FFXSR 14 /* Enable Fast FXSAVE/FXRSTOR */
#define _EFER_TCE 15 /* Enable Translation Cache Extensions */
#define _EFER_AUTOIBRS 21 /* Enable Automatic IBRS */ -
Spis hledame dokumentaci, co presne onen bit z MSR dela - CPUID flags maji totiz informacni hodnotu, neni to "nastaveni firewallu na opcody". Takze se muze jedna pouze o zabraneni detekce podpory, nez o fakticke vyrazeni podpory.
Ten komentar u citovaneho kodu by byl mnohem uzitecnejsi kdyby obsahoval referenci na AMD dokument (at uz zakladni dokumentaci, nebo errata/update co asi podobnej bug popisuje). Vetsinou jsou i bity pojmenovane skrze #define, ale tady ne. Je to proste prasarna :D
-
FíkZlatý podporovatelKdyby to tak bylo, tak nevznikne problém v CachyOS, nebo GCC obalil RDSEED nějakým systémovým voláním? Někdo si stěžoval, že GCC vůbec ten RDSEED vyrobí, když není podpora v /proc/cpuinfo, ale to je blbost, GCC se používá i na cross-compile. A zase každou instrukci nemůže obalovat kontrolou za chodu podle cpuinfo, to by bylo pomalé.
-
Dela se to tak, ze pri spusteni programu se nacachuji moznosti (at uz z runtime detekce, nebo parsovanim /proc/cpuinfo), a nasledny kod vybira ruzne funkce. (viz mplayer, ffmpeg, a jine veci ktere jsou flexibilni co se instrukcnich sad tyce).
GCC nevyrobi RDSEED - protoze nema duvod - neexistuje zadny #pragma, ktere by randomizovalo control flow. Uzivatel (programator) musi pouzit bud asm nebo intrinsics.h a explicitne si takovou operaci vyzadat pro sve potreby. Tudiz ma moznost si vyresit i legalitu sveho cineni.
-
FíkZlatý podporovatel
Jo, to automatický vybírání mezi AVX a AVX2 je jasný. GCC to myslím furt nedělá automaticky, ICC to umělo i automaticky samo. Glibc tak taky dost věcí dělá.
Mi přijde, že GCC ten RDSEED vyrobí s tím přepínačem -march=znver5, ale bez něj ne. Asi tam nebude RDSEED přímo ve zdrojáku v asm. Jinak mi ta chyba v CachyOS nedává smysl.
-
Tak RDSEED je pro generování náhodných čísel, takže předpokládám, že když někdo zavolá random() v stdlib.h, tak se někde v libc může ten RDSEED použít (zvlášť když se vyžádá -march varianta pro zen5).
To jsem řešil podobnej problém, když jsem portoval coreboot na 486. Všechno fungovalo perfektně až do chvíle, kdyz se měla vypsat kapacita paměti v megabajtech, kdyz to vždycky zhavarovalo. Nakonec mě po disassemblování došlo, že kompilátor nepoužívá integer DIV instrukce (protože ty jsou na 32bit nahouby) a dělá to předkompilovanou rutinou. Bohužel pro 486 ta rutina byla předkompilovaná pro i686 a obsahovala ENDBR (nebo něco takovýho). Takže jsem si musel zkompilovat cross-gcc speciálně jen pro 486 (a jen kvůli tomu, že se ta kapacita měla vypsat v megabajtech a ne bajtech :-D).
-
OK nedalo mi to a kouknul jsem se do poznámek, čím to přesně bylo. Nebylo to přímo kvůli výpočtu paměti, ale v samotné konverzi čísla z proměnné do ASCII hodnoty pro printf. Jak se postupně počítají jednotlivé cifry, tak to jde po desítkách a používá se modulo 10 a děleno 10 a právě tam se použila předdefinovaná funkce z gcc.
Na začátku mě nenapadlo, že gcc nepoužije DIV instrukci, takže jsem prostě zakomentoval první použití "%i" a přepsal konverzní rutinu, aby se hexadecimální a decimální výstupy počítaly nezávisle. Tím jsem se myslím dostal až do místa, kde se detekovala paměť a tyhle omezené logy začaly být neúnosné, takže jsem musel začít zjišťovat disassemblerem, kde je problém.
První použití "%i" ve vanilla corebootu je výpis verze corebootu a log level jako integer :-D.
-
Souhlas, že nemají rovnou referencovaný pdfko je opruz. Ale najít MSR_AMD64_CPUID_FN_7 jde, mě stačilo do googlu hodit "MSRc001_1002" a je to první odkaz :-D.
18 RDSEED. Read-write. Reset: Core::X86::Cpuid::StructExtFeatIdEbx0[RDSEED].
A těch R/W bitů tam je víc, třeba se dá nastavit AVX2. Předpokládám (i když je to spekulace), že vypnutí bitu zároveň vypne i dekodér toho opkódu.
Ale u toho patche by fakt chtělo, aby někdo použil symbolické jméno místo hodnoty natvrdo.
-
Ja sazim na to, ze to nemeni chovani dekoderu - jen obsah vysledku cteni CPUID.
Koukam po dalsich vecech... tohle je dobry peklo:
https://groups.google.com/g/linux.kernel/c/m3JwzwXQfxo?pli=1#688 : Processor May Cause Unpredictable Program Behavior Under Highly Specific Branch Conditions
https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/revision-guides/47534_14h_Mod_00h-0Fh_Rev_Guide.pdfA reseni je zmenit dva reserved MSR bity :D asi nejaka experimentalni feature.. zkusili jsme, nevyslo to. V procesorech je strasne hnoje asi.. pak neni divu ze to ma bugy - a vime jen o tech, na ktere se prislo... co teprve ty, ktere se schovavaji v tech reserved msr bitech...
Paranoia mode ON :D
-
Ja sazim na to, ze to nemeni chovani dekoderu - jen obsah vysledku cteni CPUID.
Hmm zkusil jsem na Ryzenu 3600, což je ale Zen 2 a asi máš pravdu, rdseed nesegfaultuje ať je ten MSR 0xC0011002 bit 18 nula nebo jedna (a vypnul jsem to pro všechny CPU). CPUID ten bit pak vrací podle nastavení.
Kód je zde, ale je to splácané z několika dotazů na chatGPT. A je to jen pro CPU#0.
V procesorech je strasne hnoje asi.. pak neni divu ze to ma bugy - a vime jen o tech, na ktere se prislo... co teprve ty, ktere se schovavaji v tech reserved msr bitech...
No já to říkám pořád, že x86 je bloatware a chtělo by to restart celé architektury tak každejch 10 let :-D.
