Re: [tip: x86/urgent] x86/CPU/AMD: Add RDSEED fix for Zen5

[Thomas Gleixner <tglx@linutronix.de>]

On Mon, Nov 03 2025 at 14:59, Peter Jung wrote:
>>   static void init_amd_zen5(struct cpuinfo_x86 *c)
>>   {
>> +	if (!x86_match_min_microcode_rev(zen5_rdseed_microcode)) {
>> +		clear_cpu_cap(c, X86_FEATURE_RDSEED);
>> +		msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18);
>> +		pr_emerg_once("RDSEED32 is broken. Disabling the corresponding CPUID bit.\n");
>> +	}
>>   }
>>   
>>   static void init_amd(struct cpuinfo_x86 *c)
>
> This fix seems to break quite a bunch of users in CachyOS. There has 
> been now several users reporting that there system can not get properly 
> into the graphical interface.
>
> CachyOS is compiling the packages with -march=znver5 and the GCC 
> compiler currently does pass RDSEED.

You get what you ask for. You build a binary for a CPU which does
not provide a functional correct RDSEED16/32 instruction.

> This patch results into that also Client CPUs (Strix Point, Granite 
> Ridge), can not execute this. There has been a microcode fix deployed in 
> linux-firmware for Turin, but no other microcode changes seen yet.
>
> I think it would be possible to exclude clients or providing a fix for this.

There are only two fixes:

      1) New microcode

      2) Fix all source code to either use the 64bit variant of RDSEED
         or check the result for 0 and treat it like RDSEED with CF=0
         (fail) or make it check the CPUID bit....

New microcode will come around soon and fixing all source code is not
possible.

Excluding clients is not an option because that leaves anything crypto
related which relies on randomness with a big hole. Clients require
functional crypto as much as any other system, no?

So the only workaround for now is to use a build which does not emit
RDSEED or checks CPUID for availability before blindly using it.

Thanks,

        tglx