Linus|x úgy döntött, hogy letiltja az RNG-t az összes AMD fTPM-en

AMD

tl;dr: Tavaly az AMD egy figyelmeztetést adott ki az újabb Ryzen rendszerek tulajdonosai számára: Időszakos rendszerakadozás tapasztalható fTPM engedélyezésekor a Windows® 10 és 11 rendszereken. BIOS frissítést és egyéb kerülőmegoldásokat javasolt. Noha kezdetben úgy tűnt, hogy az akadozás probléma csak Windows felhasználókat érint, kiderült, hogy a Linux usereket is érintheti.

Sajnos a BIOS frissítés nem mindenki számára volt opció, tekintve, hogy nem minden gyártó adott ki javított BIOS verziót. Mivel a Linux 6.1-től a Linux kernel alapértelmezetten az AMD fTPM véletlenszám-generátorát használta a megfelelő rendszereken, a Linux userek is egyre nagyobb számban kezdtek panaszkodni az akadozásra.

Ugorjuk előre fél évet ... Linus egyre frusztráltabbá vált az AMD fTPM hardveres véletlenszám-generátorának hibái miatt, amelyek a legújabb Ryzen rendszereken sújtják a kernelt, ezért jelezte, hogy letiltaná a támogatást:

Let's just disable the stupid fTPM hwrnd thing.

Maybe use it for the boot-time "gather entropy from different sources", but clearly it should *not* be used at runtime.

Why would anybody use that crud when any machine that has it supposedly fixed (which apparently didn't turn out to be true after all) would also have the CPU rdrand instruction that doesn't have the problem?

If you don't trust the CPU rdrand implementation (and that has had bugs too - see clear_rdrand_cpuid_bit() and x86_init_rdrand()), why would you trust the fTPM version that has caused even *more* problems?

Erre válaszként Marion Limonciello, az AMD Linux mérnöke készített egy patchet:

tpm: Disable RNG for all AMD fTPMs

The TPM RNG functionality is not necessary for entropy when the CPU already supports the RDRAND instruction. The TPM RNG functionality was previously disabled on a subset of AMD fTPM series, but reports continue to show problems on some systems causing stutter root caused to TPM RNG functionality.

Expand disabling TPM RNG use for all AMD fTPMs whether they have versions that claim to have fixed or not.

A patchet tegnap be is olvasztotta Linus a mainline kernelbe. Remélhetőleg ezzel pont kerül azoknak az akadozási problémáknak a végére, amelyeket az AMD-s Linux felhasználók tapasztaltak az újabb Linux kernelekkel.

Lehet fölényeskedni, de szerencsére nem múlt héten szoptam egy Inteles gép EFI firmware bugjaival, hogy csak SATA-ról volt hajlandó megbízhatóan bootolni, NVME-ről nem (random data trashing kernel betöltés közben). Öööö.... Ja, de!

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nem biztos, nekem Whiskey Lake processzorom (Intel® Core™ i7-8565U) van :D

+/* CPU is affected by GDS */
+#define GDS		BIT(5)
 
 static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
 	VULNBL_INTEL_STEPPINGS(IVYBRIDGE,	X86_STEPPING_ANY,		SRBDS),
@@ -1279,19 +1281,21 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
 	VULNBL_INTEL_STEPPINGS(BROADWELL_X,	X86_STEPPING_ANY,		MMIO),
 	VULNBL_INTEL_STEPPINGS(BROADWELL,	X86_STEPPING_ANY,		SRBDS),
 	VULNBL_INTEL_STEPPINGS(SKYLAKE_L,	X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(SKYLAKE_X,	X86_STEPPING_ANY,		MMIO | RETBLEED),
+	VULNBL_INTEL_STEPPINGS(SKYLAKE_X,	X86_STEPPING_ANY,		MMIO | RETBLEED | GDS),
 	VULNBL_INTEL_STEPPINGS(SKYLAKE,		X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(KABYLAKE_L,	X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(KABYLAKE,	X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED),
+	VULNBL_INTEL_STEPPINGS(KABYLAKE_L,	X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED | GDS),
+	VULNBL_INTEL_STEPPINGS(KABYLAKE,	X86_STEPPING_ANY,		SRBDS | MMIO | RETBLEED | GDS),
 	VULNBL_INTEL_STEPPINGS(CANNONLAKE_L,	X86_STEPPING_ANY,		RETBLEED),
-	VULNBL_INTEL_STEPPINGS(ICELAKE_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(ICELAKE_D,	X86_STEPPING_ANY,		MMIO),
-	VULNBL_INTEL_STEPPINGS(ICELAKE_X,	X86_STEPPING_ANY,		MMIO),
-	VULNBL_INTEL_STEPPINGS(COMETLAKE,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED),
+	VULNBL_INTEL_STEPPINGS(ICELAKE_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL_STEPPINGS(ICELAKE_D,	X86_STEPPING_ANY,		MMIO | GDS),
+	VULNBL_INTEL_STEPPINGS(ICELAKE_X,	X86_STEPPING_ANY,		MMIO | GDS),
+	VULNBL_INTEL_STEPPINGS(COMETLAKE,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
 	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED),
+	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL_STEPPINGS(TIGERLAKE_L,	X86_STEPPING_ANY,		GDS),
+	VULNBL_INTEL_STEPPINGS(TIGERLAKE,	X86_STEPPING_ANY,		GDS),
 	VULNBL_INTEL_STEPPINGS(LAKEFIELD,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(ROCKETLAKE,	X86_STEPPING_ANY,		MMIO | RETBLEED),
+	VULNBL_INTEL_STEPPINGS(ROCKETLAKE,	X86_STEPPING_ANY,		MMIO | RETBLEED | GDS),
 	VULNBL_INTEL_STEPPINGS(ATOM_TREMONT,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS),
 	VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_D,	X86_STEPPING_ANY,		MMIO),
 	VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS),

trey @ gépház

( aszijg v | 2023. 08. 08., k – 13:06 )

Egy Ryzen 7-es ketyeg a laptopomban, de még ezt a jelenséget nem tapasztaltam.

de még ezt a jelenséget nem tapasztaltam

Én sem 🤷‍♂️

trey@alderaan:~$ cat /proc/cpuinfo | grep I
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
vendor_id    : GenuineIntel
model name    : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
 

trey @ gépház

Félig értek egyet. Ha mobil 8. genről beszélünk, akkor igen, igazad van, nagy volt a fejlődés, de a 8. gen is használható még azért. Az asztali 8 gen viszont ma is teljesen jó még, ez volt az első olyan Intel generáció, ahol az Intel összekapta magát, és beszüntette ezt a mindenkinek 2-4 mag szintű, óvatos tikk-takkozós hülyeségét, így nehezebben avult el. Persze, felhasználásfüggő is, kinek mi kell.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az csak 4 mag, de igen, 8 szál, és nem egy rossz proci ma sem, kellően energiatakarékos. Nekem is teljesen jó lenne, bőven lefedné az igényeim még sok évig. Az én laptopomon hiába van 8 mag, 16 szál, meg turbózik 4,8 GHz közelébe a Ryzen 6800H, és többször annyi a cache, ha nálam nem 10%-on, hanem csak 1-2%-on ketyeg. Kicsit overkill a sovány ablakkezelő és terminálos alkalmazások alá, de ha mondjuk játszok, vagy nagyobb kódot kell lefordítani, ott hasznosul.

Szerintem ahol az Intel mobilprocik gyorsan avulnak, az nem a processzorerő, hanem az integrált GPU-s rész, nyilván ez akkor fontos, ha nincs a gépben dedikált GPU. Bár ez se mindenkinek fontos.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( x-daemon | 2023. 08. 08., k – 14:08 )

pont tegnap lett egy "akadozasom" miutan kicsereltem az egeremet. feltetelezem felszaladt az irq es emiatt minden lagolt. dmesgben 1-2 masodpercenkent "reset low-speed USB device number 3 using xhci_hcd" volt. hiaba dugtam vissza az elozo egeret, a problema megmaradt. ellenben mikor a billentyuzetet atdugtam masik portba, a problema megszunt.

neked aztan fura humorod van...

( YleGreg | 2023. 08. 08., k – 14:53 )

Nekem ez fura. Amennyire tudom, a random szamok generalasahoz jo ha van minel tobb entropia. A TPM chipek meg arrol hiresek, hogy zarkozott termeszetuek, es magasrol tesznek a kornyezetukre.

Nem a CPU az, ahol a legtobb entropia ossze tud gyulni, pontosabban nem a CPU az, ami a legtobb sztohasztikusnak mondhato adatforrast el tudja erni?

hw rng mar 20 eve is volt pc-ken, de sose volt tul megbizhato, inkabb arra jo hogy a kezdeti entropiahoz/seed-hez felhasznald de utana mar felejtos vagy max idonkent hozza lehetett xor-olni.

beagyazott rendszerhez mi is epitettunk, a zajt kellett jol felerositeni aztan digitalis bemenetre kotni, de nem volt egyenletes meg neha elegge random se...

Ez nem olyan, mint a kernel szoftveres random poolja, ami - jobb híján - interruptokból és hasonló külső eredetű eseményekből próbál entrópiát szerezni.

Tipikusan úgy működik, hogy van valami kaotikus viselkedésű áramkör (van erre néhány egyszerű, szembekötött diódapáros alapkapcsolás ami már bizonyos előfeszítés mellett kaotikus viselkedést mutat). Ezt mintavételezik, és - mivel a kaotikus függvények rövidtávon még megjósolhatók - még mindenféle transzformálást (FFT?) csinálnak rajta, a kapott eredmény determinisztikus részét eldobják. Közben van mindenféle monitorozó funkció, ami ellenőrzi, hogy az alapáramkör biztosan a kaotikus működési tartományban van-e, hogy a mintavételezett jelnek mennyi az entrópiatartalma stb. Elvileg le kell tudnia állni és hibát jelezni, ha a kapott adat már nem garantáltan véletlenszerű.

További bonyolítás, hogy a fenti módszerrel nem lehet túl sok entrópiát generálni, tudtommal pár 10-100 kByte/s-el tud random adatot szolgáltatni. Ezért ezt szinte mindig úgy használják, hogy van egy gyors (akár több GB/s-es) pszeudo-random generátor, amit folyamatosan újra seedelnek a valós random forrással.

Ilyenből lehet több is a CPU-ban. Az egyik, amit az RDRAND utasítással érsz el. Egy másik van a TPM-ben.

Baj #1: a fent említett monitorozás igazából nem tesztelhető, nem tudod készakarva leállítani a hardveres eredeti random forrást, hogy ellenőrizd, hogy tényleg jelzi-e a hibáját

Baj #2: a pszeudorandom generátor algoritmusa általában nem publikus, ezért nem tudod ellenőrizni, hogy az újraseedelés ténylegesen megtörténik-e és milyen sűrűn

Baj #3: (ilyen bug ténylegesen volt régi ~K10-es AMD-kben) - előfordul, hogy valami CPU power saving állapotváltásnál a random generátor egy része vagy egésze leáll. Bizonyos körülmények között előfordul, hogy "elfelejt" elindulni, mikor a CPU felébred. Annyiban jó volt, hogy csupa 0-kat adott vissza az RDRAND, így legalább detektálható volt.

Baj #4: (mostani bug) A TPM-es random forrásból olvasás belül csinál mindenféle furcsa, tkp indokolatlan dolgot is (ROM-ból olvasás stb.), ami időnként nagyon lassúvá teszi.

Régóta vágyok én, az androidok mezonkincsére már!

Szokták azt csinálni, hogy Si bipoláris tranzisztor emitter-bázis átmenetét záróirányban előfeszítik, az jellemzően 7 V környékén letörésbe megy, de csak nagyon kis árammal teszik, hogy ne tegyék tönkre. Ez borzasztó zajos, erősítik, majd A/D konvertálják, s megvan a fizikai alapú, részben termikus, és megannyi folyamattól függő zaj.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE