1. Patchew
  2. Xen
  3. [PATCH v3 0/2] x86/AMD: deal with RDSEED issues
  4. View patch

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

Jan Beulich posted 2 patches 1 day, 23 hours ago
[PATCH v3 2/2] x86/AMD: disable RDSEED on problematic Zen5
Posted by Jan Beulich 1 day, 23 hours ago 
This particular variant has an error that causes 16- and 32-bit forms of
RDSEED to frequently return 0 while still signaling success (CF=1). Refer
to AMD-SB-7055 / CVE-2025-62626.

Relevant data taken from Linux commits 607b9fb2ce24 ("x86/CPU/AMD: Add
RDSEED fix for Zen5") and e1a97a627cd0 ("x86/CPU/AMD: Add additional fixed
RDSEED microcode revisions").

Like for the other RDSEED issue, the same command line override can be
used to keep RDSEED enabled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
See "x86/AMD: disable RDSEED on Fam17 model 47 stepping 0" for pending
opens.

The choice of using AVX-IFMA to tell Zen6 from Zen5 is somewhat arbitrary;
a few other features could equally(?) well be used.

I will admit that I was on the edge of switching to a table-based
approach. (I'm also not happy with the case 0x44 layout, but keeping the
"break" on the earlier line triggers [imo bogusly] gcc's "misleading
indentation" warning. We could of course move yet farther away from the
Linux originals and use switch(curr_rev >> 8), like we do in
zenbleed_use_chickenbit() and amd_check_entrysign().)
---
v3: Incorporate another Linux commit. Cover Zen6, assuming it is
    universally unaffected.
v2: New.

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -863,6 +863,28 @@ static void cf_check fam17_disable_c6(vo
 	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
 }
 
+static noinline bool __init zen5_rdseed_good(const struct cpuinfo_x86 *c)
+{
+    unsigned int curr_rev = this_cpu(cpu_sig).rev, fixed_rev = ~0;
+
+    switch ( c->model )
+    {
+    case 0x02: if ( c->stepping == 1 ) fixed_rev = 0x0b00215a; break;
+    case 0x08: if ( c->stepping == 1 ) fixed_rev = 0x0b008121; break;
+    case 0x11: if ( c->stepping == 0 ) fixed_rev = 0x0b101054; break;
+    case 0x24: if ( c->stepping == 0 ) fixed_rev = 0x0b204037; break;
+    case 0x44: if ( c->stepping == 0 ) fixed_rev = 0x0b404035;
+               if ( c->stepping == 1 ) fixed_rev = 0x0b404108;
+               break;
+    case 0x60: if ( c->stepping == 0 ) fixed_rev = 0x0b600037; break;
+    case 0x68: if ( c->stepping == 0 ) fixed_rev = 0x0b608038; break;
+    case 0x70: if ( c->stepping == 0 ) fixed_rev = 0x0b700037; break;
+    default:   if ( cpu_has_avx_ifma ) fixed_rev = 0 /* Zen6 */; break;
+    }
+
+    return curr_rev >= fixed_rev;
+}
+
 static bool zenbleed_use_chickenbit(void)
 {
     unsigned int curr_rev;
@@ -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.
+		 */
+		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;
 	}
 
 	display_cacheinfo(c);
Re: [PATCH v3 2/2] x86/AMD: disable RDSEED on problematic Zen5
Posted by Teddy Astie 1 day, 22 hours ago 
Le 16/12/2025 à 10:03, Jan Beulich a écrit :
> This particular variant has an error that causes 16- and 32-bit forms of
> RDSEED to frequently return 0 while still signaling success (CF=1). Refer
> to AMD-SB-7055 / CVE-2025-62626.
> 
> Relevant data taken from Linux commits 607b9fb2ce24 ("x86/CPU/AMD: Add
> RDSEED fix for Zen5") and e1a97a627cd0 ("x86/CPU/AMD: Add additional fixed
> RDSEED microcode revisions").
> 
> Like for the other RDSEED issue, the same command line override can be
> used to keep RDSEED enabled.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> See "x86/AMD: disable RDSEED on Fam17 model 47 stepping 0" for pending
> opens.
> 
> The choice of using AVX-IFMA to tell Zen6 from Zen5 is somewhat arbitrary;
> a few other features could equally(?) well be used.
> 
> I will admit that I was on the edge of switching to a table-based
> approach. (I'm also not happy with the case 0x44 layout, but keeping the
> "break" on the earlier line triggers [imo bogusly] gcc's "misleading
> indentation" warning. We could of course move yet farther away from the
> Linux originals and use switch(curr_rev >> 8), like we do in
> zenbleed_use_chickenbit() and amd_check_entrysign().)
> ---
> v3: Incorporate another Linux commit. Cover Zen6, assuming it is
>      universally unaffected.
> v2: New.
> 
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -863,6 +863,28 @@ static void cf_check fam17_disable_c6(vo
>   	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
>   }
>   
> +static noinline bool __init zen5_rdseed_good(const struct cpuinfo_x86 *c)
> +{
> +    unsigned int curr_rev = this_cpu(cpu_sig).rev, fixed_rev = ~0;
> +
> +    switch ( c->model )
> +    {
> +    case 0x02: if ( c->stepping == 1 ) fixed_rev = 0x0b00215a; break;
> +    case 0x08: if ( c->stepping == 1 ) fixed_rev = 0x0b008121; break;
> +    case 0x11: if ( c->stepping == 0 ) fixed_rev = 0x0b101054; break;
> +    case 0x24: if ( c->stepping == 0 ) fixed_rev = 0x0b204037; break;
> +    case 0x44: if ( c->stepping == 0 ) fixed_rev = 0x0b404035;
> +               if ( c->stepping == 1 ) fixed_rev = 0x0b404108;
> +               break;
> +    case 0x60: if ( c->stepping == 0 ) fixed_rev = 0x0b600037; break;
> +    case 0x68: if ( c->stepping == 0 ) fixed_rev = 0x0b608038; break;
> +    case 0x70: if ( c->stepping == 0 ) fixed_rev = 0x0b700037; break;
> +    default:   if ( cpu_has_avx_ifma ) fixed_rev = 0 /* Zen6 */; break;
> +    }
> +
> +    return curr_rev >= fixed_rev;
> +}
> +
>   static bool zenbleed_use_chickenbit(void)
>   {
>       unsigned int curr_rev;
> @@ -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 ?

> +		 */
> +		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 ?

>   	}
>   
>   	display_cacheinfo(c);
> 
> 



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [PATCH v3 2/2] x86/AMD: disable RDSEED on problematic Zen5
Posted by Jan Beulich 1 day, 21 hours ago 
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

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.