Re: [PATCH v2 for-4.21 0/2] x86/AMD: deal with RDSEED issues

[Jan Beulich <jbeulich@xxxxxxxx>]

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