[PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[Gregory Price]

Under unknown architectural conditions, Zen5 chips running rdseed
can produce (val=0,CF=1) as a "random" result over 10% of the time
(when rdseed is successful).  CF=1 indicates success, while val=0
is typically only produced when rdseed fails (CF=0).

This suggests there is an architectural issue which causes rdseed
to misclassify a failure as a success under unknown conditions.

This was reproduced reliably by launching 2-threads per available
core, 1-thread per for hamming on RDSEED, and 1-thread per core
collectively eating and hammering on ~90% of memory.

Fix was modeled after a different RDSEED issue in Zen2 Cyan Skillfish.

Link: https://lore.kernel.org/all/20250715130819.461718765@linuxfoundation.org/
Cc: <stable@kernel.org>
Signed-off-by: Gregory Price <gourry@gourry.net>
---
 arch/x86/kernel/cpu/amd.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 5398db4dedb4..9c3b2f010f8c 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1037,6 +1037,12 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
 
 static void init_amd_zen5(struct cpuinfo_x86 *c)
 {
+	/* Disable RDSEED on AMD Turin because of an error. */
+	if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {
+		clear_cpu_cap(c, X86_FEATURE_RDSEED);
+		msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18);
+		pr_emerg("RDSEED is not reliable on this platform; disabling.\n");
+	}
 }
 
 static void init_amd(struct cpuinfo_x86 *c)
-- 
2.51.0

Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[Gregory Price]

On Thu, Oct 16, 2025 at 02:21:07PM -0400, Gregory Price wrote:
> Under unknown architectural conditions, Zen5 chips running rdseed
> can produce (val=0,CF=1) as a "random" result over 10% of the time
> (when rdseed is successful).  CF=1 indicates success, while val=0
> is typically only produced when rdseed fails (CF=0).
> 
> This suggests there is an architectural issue which causes rdseed
> to misclassify a failure as a success under unknown conditions.
> 
> This was reproduced reliably by launching 2-threads per available
> core, 1-thread per for hamming on RDSEED, and 1-thread per core
> collectively eating and hammering on ~90% of memory.
> 
> Fix was modeled after a different RDSEED issue in Zen2 Cyan Skillfish.
> 
> Link: https://lore.kernel.org/all/20250715130819.461718765@linuxfoundation.org/
> Cc: <stable@kernel.org>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
>  arch/x86/kernel/cpu/amd.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 5398db4dedb4..9c3b2f010f8c 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1037,6 +1037,12 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
>  
>  static void init_amd_zen5(struct cpuinfo_x86 *c)
>  {
> +	/* Disable RDSEED on AMD Turin because of an error. */
> +	if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {

After re-examining the results, this was also observed on

  c->x86_model == 0x2

Maybe this should just be disabled for all of Zen5?
I will wait for comment.

In a stress test (link) I found that my Zen5 chips have a bizarrely
low rdseed success rate anyway - so it doesn't even seem useful.

./rdseed_stress_single_core
RDRAND: 100.00%, RDSEED: 3.48%

./rdseed_stress_multi_thread
RDRAND: 99.99%, RDSEED: 0.33%

Link: https://lore.kernel.org/all/Zbjw5hRHr_E6k18r@zx2c4.com/

---

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9c3b2f010f8c..54f07514674a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1038,7 +1038,8 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
 static void init_amd_zen5(struct cpuinfo_x86 *c)
 {
        /* Disable RDSEED on AMD Turin because of an error. */
-       if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {
+       if ((c->x86_model == 0x11 || c->x86_model == 0x2) &&
+           (c->x86_stepping == 0x0)) {
                clear_cpu_cap(c, X86_FEATURE_RDSEED);
                msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18);
                pr_emerg("RDSEED is not reliable on this platform; disabling.\n");

Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[H. Peter Anvin]

On October 16, 2025 12:12:31 PM PDT, Gregory Price <gourry@gourry.net> wrote:
>On Thu, Oct 16, 2025 at 02:21:07PM -0400, Gregory Price wrote:
>> Under unknown architectural conditions, Zen5 chips running rdseed
>> can produce (val=0,CF=1) as a "random" result over 10% of the time
>> (when rdseed is successful).  CF=1 indicates success, while val=0
>> is typically only produced when rdseed fails (CF=0).
>> 
>> This suggests there is an architectural issue which causes rdseed
>> to misclassify a failure as a success under unknown conditions.
>> 
>> This was reproduced reliably by launching 2-threads per available
>> core, 1-thread per for hamming on RDSEED, and 1-thread per core
>> collectively eating and hammering on ~90% of memory.
>> 
>> Fix was modeled after a different RDSEED issue in Zen2 Cyan Skillfish.
>> 
>> Link: https://lore.kernel.org/all/20250715130819.461718765@linuxfoundation.org/
>> Cc: <stable@kernel.org>
>> Signed-off-by: Gregory Price <gourry@gourry.net>
>> ---
>>  arch/x86/kernel/cpu/amd.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index 5398db4dedb4..9c3b2f010f8c 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -1037,6 +1037,12 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
>>  
>>  static void init_amd_zen5(struct cpuinfo_x86 *c)
>>  {
>> +	/* Disable RDSEED on AMD Turin because of an error. */
>> +	if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {
>
>After re-examining the results, this was also observed on
>
>  c->x86_model == 0x2
>
>Maybe this should just be disabled for all of Zen5?
>I will wait for comment.
>
>In a stress test (link) I found that my Zen5 chips have a bizarrely
>low rdseed success rate anyway - so it doesn't even seem useful.
>
>./rdseed_stress_single_core
>RDRAND: 100.00%, RDSEED: 3.48%
>
>./rdseed_stress_multi_thread
>RDRAND: 99.99%, RDSEED: 0.33%
>
>Link: https://lore.kernel.org/all/Zbjw5hRHr_E6k18r@zx2c4.com/
>
>---
>
>diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>index 9c3b2f010f8c..54f07514674a 100644
>--- a/arch/x86/kernel/cpu/amd.c
>+++ b/arch/x86/kernel/cpu/amd.c
>@@ -1038,7 +1038,8 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
> static void init_amd_zen5(struct cpuinfo_x86 *c)
> {
>        /* Disable RDSEED on AMD Turin because of an error. */
>-       if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {
>+       if ((c->x86_model == 0x11 || c->x86_model == 0x2) &&
>+           (c->x86_stepping == 0x0)) {
>                clear_cpu_cap(c, X86_FEATURE_RDSEED);
>                msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18);
>                pr_emerg("RDSEED is not reliable on this platform; disabling.\n");

Let's be blunt (and this applies regardless of vendor, the same thing would apply to Intel chips): RDSEED *must not* be allowed to silently fail. Period. The whole *point* of RDSEED is that it is to unconditionally deliver a fully entropic random result. 

This affects user space applications, not just the kernel 

As such, it is absolutely necessary to be conservative here. The vendor (in this case AMD) can then root-cause the failure and provide a narrower blacklist when the true extent is known.

Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[Borislav Petkov]

On Thu, Oct 16, 2025 at 12:39:43PM -0700, H. Peter Anvin wrote:
> The vendor (in this case AMD) can then root-cause the failure and provide
> a narrower blacklist when the true extent is known.

Yap, we're looking into this, ofc.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

[Jason A. Donenfeld]

On Thu, Oct 16, 2025 at 02:21:07PM -0400, Gregory Price wrote:
> Under unknown architectural conditions, Zen5 chips running rdseed
> can produce (val=0,CF=1) as a "random" result over 10% of the time
> (when rdseed is successful).  CF=1 indicates success, while val=0
> is typically only produced when rdseed fails (CF=0).
> 
> This suggests there is an architectural issue which causes rdseed
> to misclassify a failure as a success under unknown conditions.
> 
> This was reproduced reliably by launching 2-threads per available
> core, 1-thread per for hamming on RDSEED, and 1-thread per core
> collectively eating and hammering on ~90% of memory.
> 
> Fix was modeled after a different RDSEED issue in Zen2 Cyan Skillfish.

Yikes. I suppose we should get some more info from AMD, so that they can
really figure out what's affected and why and such. In the meanwhile,
maybe it makes sense to disable a broad set of Zen 5 subfamilies? From a
random.c perspective, it'll use RDRAND instead, which appears to be
unaffected according to your report.

(Though, how could you tell if it was affected? RDRAND runs everything
 through its internal DRBG, so if part of the key that it uses is made of
 fixed zeros, we probably wouldn't notice. AMD really needs to look into
 this.)

Impact-wise on random.c, assuming the most pessimistic conditions -- no
other entropy source being used other than RDSEED, which is never
actually the case but good for analysis here -- the first usage of
getrandom() will use 512 bits (random_init_early()) + 256 bits
(extract_entropy()) = 768 bits of RDSEED output, so assuming your 10%
failure rate, that's still 688 bits, which is roughly 2.69x as much as
we really "need" anyway. So I suspect overkill engineering is saving us
a bit here, and there's not any security impact to random.c.

Users who don't use getrandom() and try to use RDSEED directly might be
in a different situation, however. Don't do this. Just use getrandom().

Jason