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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878qgnw0vt.ffs@tglx>
Date: Mon, 03 Nov 2025 17:12:54 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Jung <ptr1337@...hyos.org>, linux-kernel@...r.kernel.org,
 linux-tip-commits@...r.kernel.org
Cc: stable@...r.kernel.org, Gregory Price <gourry@...rry.net>, "Borislav
 Petkov (AMD)" <bp@...en8.de>, x86@...nel.org
Subject: Re: [tip: x86/urgent] x86/CPU/AMD: Add RDSEED fix for Zen5

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