On 03.11.2025 15:10, Andrew Cooper wrote: > On 28/10/2025 3:32 pm, Jan Beulich wrote: >> Both patches also want 'x86/CPU: extend is_forced_cpu_cap()'s "reach"' in >> place. >> >> 1: disable RDSEED on Fam17 model 47 stepping 0 >> 2: disable RDSEED on most of Zen5 > > We have two existing cases for RDRAND issues in Xen: > > 1) IvyBridge SRBDS speculative vulnerability. Here, the RNG is good, > but use of the RDRAND instruction can allow another entity on the system > to observe the random number. RDRAND is off by default, but can be > opted in to. > > 2) AMD Fam15/16h Laptop. Here, the RNG is fine, except after S3 on one > single OEM. Use of RDRAND can be activated on the command line, but > there's no ability for individual VMs to opt in. Being a laptop, > migration isn't a major concern. > > > For this seres about RDSEED, we've got: > > 1) Cyan Skillfish, the PlayStation 5 CPU but also in one crypto-mining > rig. Here, RDSEED is deterministically broken and not getting a fix. > > The chances of Xen running on these systems is almost 0. We should turn > off RDSEED and be done with it; it's not interesting in the slightest to > be able to turn back on.
I disagree to some degree, but the code to allow re-enabling can certainly be moved to the other patch. I don't view it as wrong to have it in the 1st patch, though. > 2) Zen5. Here, RDSEED gives a higher-than-expected rate of 0's for only > the 32bit and 16bit forms; the 64bit form is unaffected. > > There is microcode to fix it, on server at least. Firmware fixes for > client are rather further away. 64bit OSes are likely fine (using the > 64bit instruction form). Some Linux devs think that Linux would be safe > even using the 32bit form, if it really only has a 10% zeroes rate. 10% is a lot. IOW I find this dubious. > There is certainly a risk that software uses the 32b/16b forms, and not > mix it properly with other entropy, but the common case these days (64b) > works just fine. This means that blanket-disabling does more harm than > good. That's guesswork. I don't see why 64-bit OSes should be expected to prefer the 64-bit form over the 32-bit one. In fact, if one only needs 32 bits of entropy, why would one even try to get 64? That's wasting a potentially precious resource. Furthermore mind me mentioning (again) that 32-bit OSes (including 32-bit environments that may be active during boot) have no way of using the 64- bit form? Jan
