The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 607b9fb2ce248cc5b633c5949e0153838992c152 Gitweb: https://git.kernel.org/tip/607b9fb2ce248cc5b633c5949e0153838992c152 Author: Gregory Price gourry@gourry.net AuthorDate: Mon, 20 Oct 2025 11:13:55 +02:00 Committer: Borislav Petkov (AMD) bp@alien8.de CommitterDate: Tue, 28 Oct 2025 12:37:49 +01:00
x86/CPU/AMD: Add RDSEED fix for Zen5
There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail.
Add a fix glue which checks microcode revisions.
[ bp: Add microcode revisions checking, rewrite. ]
Cc: stable@vger.kernel.org Signed-off-by: Gregory Price gourry@gourry.net Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net --- arch/x86/kernel/cpu/amd.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index ccaa51c..bc29be6 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1035,8 +1035,18 @@ static void init_amd_zen4(struct cpuinfo_x86 *c) } }
+static const struct x86_cpu_id zen5_rdseed_microcode[] = { + ZEN_MODEL_STEP_UCODE(0x1a, 0x02, 0x1, 0x0b00215a), + ZEN_MODEL_STEP_UCODE(0x1a, 0x11, 0x0, 0x0b101054), +}; + 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)
Hi,
On Tue, Oct 28, 2025 at 12:01:51PM -0000, tip-bot2 for Gregory Price wrote:
x86/CPU/AMD: Add RDSEED fix for Zen5
There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail.
Add a fix glue which checks microcode revisions.
[ bp: Add microcode revisions checking, rewrite. ]
Cc: stable@vger.kernel.org Signed-off-by: Gregory Price gourry@gourry.net Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net
I didn't see this on LKML or any mailing list before this appeared in tip. Did I miss something?
Jason
On Thu, Oct 30, 2025 at 07:05:16PM +0100, Jason A. Donenfeld wrote:
I didn't see this on LKML or any mailing list before this appeared in tip. Did I miss something?
Also, by the way,
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html
Until the microcode patch is deployed, the following software workaround options could be used:
[...]
- Software can treat RDSEED returning 0 equivalent to when CF=0. Retry RDSEED later until a non-zero value is returned with CF=1
You sure that's such a good idea?
Jason
On 10/28/25 13:01, tip-bot2 for Gregory Price wrote:
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 607b9fb2ce248cc5b633c5949e0153838992c152 Gitweb:https://git.kernel.org/tip/607b9fb2ce248cc5b633c5949e0153838992c152 Author: Gregory Pricegourry@gourry.net AuthorDate: Mon, 20 Oct 2025 11:13:55 +02:00 Committer: Borislav Petkov (AMD)bp@alien8.de CommitterDate: Tue, 28 Oct 2025 12:37:49 +01:00
x86/CPU/AMD: Add RDSEED fix for Zen5
There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail.
Add a fix glue which checks microcode revisions.
[ bp: Add microcode revisions checking, rewrite. ]
Cc:stable@vger.kernel.org Signed-off-by: Gregory Pricegourry@gourry.net Signed-off-by: Borislav Petkov (AMD)bp@alien8.de Link:https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net
arch/x86/kernel/cpu/amd.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index ccaa51c..bc29be6 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1035,8 +1035,18 @@ static void init_amd_zen4(struct cpuinfo_x86 *c) } } +static const struct x86_cpu_id zen5_rdseed_microcode[] = {
- ZEN_MODEL_STEP_UCODE(0x1a, 0x02, 0x1, 0x0b00215a),
- ZEN_MODEL_STEP_UCODE(0x1a, 0x11, 0x0, 0x0b101054),
+};
- 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)
Hi all,
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.
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.
Example log:
Nov 03 13:37:33 hells drkonqi-coredump-processor[1073]: Incompatible processor. This Qt build requires the following features: Nov 03 13:37:33 hells drkonqi-coredump-processor[1073]: rdseed Nov 03 13:37:33 hells systemd-coredump[1077]: Process 1073 (drkonqi-coredum) of user 0 terminated abnormally with signal 6/ABRT, processing... Nov 03 13:37:33 hells systemd[1]: Started Process Core Dump (PID 1077/UID 0). Nov 03 13:37:33 hells systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling. Nov 03 13:37:33 hells drkonqi-coredump-processor[1079]: Incompatible processor. This Qt build requires the following features: Nov 03 13:37:33 hells drkonqi-coredump-processor[1079]: rdseed Nov 03 13:37:33 hells systemd-coredump[1082]: Process 1079 (drkonqi-coredum) of user 0 terminated abnormally with signal 6/ABRT, processing... Nov 03 13:37:33 hells systemd-coredump[1071]: Process 1049 (sddm) of user 0 dumped core.
Best regards,
Peter
On Mon, Nov 03, 2025 at 02:59:11PM +0100, Peter Jung wrote:
CachyOS is compiling the packages with -march=znver5 and the GCC compiler currently does pass RDSEED.
Yah, the compiler should not *pass* RDSEED, but issue code which checks whether RDSEED is there. Otherwise what's the point of CPUID flags?!
I guess this should make those boxes boot but damn, that ain't right:
--- diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 8e36964a7721..810be49dad31 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1044,8 +1044,7 @@ 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"); + WARN_ONCE(1, "RDSEED32 is broken. Disabling the corresponding CPUID bit.\n"); } }
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.
Client fixes are getting ready but I can't tell you when they'll be there.
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
linux-stable-mirror@lists.linaro.org
-
Borislav Petkov -
Jason A. Donenfeld -
Peter Jung -
Thomas Gleixner -
tip-bot2 for Gregory Price