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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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.

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.

This case does really want to be off by default (given no microcode),
but able to be opted in to.  At least one major class of OSes (Linux)
are safe despite the issue.

~Andrew