Re: [PATCH v3 2/2] x86/AMD: disable RDSEED on problematic Zen5

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.12.2025 11:08, Teddy Astie wrote:
> Le 16/12/2025 à 10:03, Jan Beulich a écrit :
>> @@ -1130,6 +1152,28 @@ static void cf_check init_amd(struct cpu
>>                  !cpu_has(c, X86_FEATURE_BTC_NO))
>>                      setup_force_cpu_cap(X86_FEATURE_BTC_NO);
>>              break;
>> +
>> +    case 0x1a:
>> +            /*
>> +             * Zen5 have an error that causes the 16- and 32-bit forms of
>> +             * RDSEED to frequently return 0 while signaling success (CF=1).
>> +             * Sadly at the time of writing the fixed microcode revision is
>> +             * known for only two of the models.
> 
> Is it still two models ?

Oops - s/two/some/. Thanks for noticing.

>> +             */
>> +            if (c == &boot_cpu_data &&
>> +                cpu_has(c, X86_FEATURE_RDSEED) &&
>> +                !is_forced_cpu_cap(X86_FEATURE_RDSEED)) {
>> +                    static const char __initconst text[] =
>> +                            "RDSEED32 is unreliable on this hardware; 
>> disabling its exposure\n";
>> +
>> +                    if (zen5_rdseed_good(c))
>> +                            break;
>> +
>> +                    setup_clear_cpu_cap(X86_FEATURE_RDSEED);
>> +                    cpuidmask_defaults._7ab0 &= 
>> ~cpufeat_mask(X86_FEATURE_RDSEED);
>> +                    warning_add(text);
>> +            }
>> +            break;
> 
> Do we still want to disable if we are running in a hypervisor; we can 
> expect the host to emulate the instructions to workaround the issue ?

That would only work if we knew the host intercepts that insn. We don't
ourselves, so I can't see us legitimately expecting anyone else to do so. Plus
while I'm aware RDSEED can be intercepted on VMX, I'm unaware of there being
equivalent functionality on SVM (PM vol 3 does not yield any hit when searching
for RDSEED).

Jan