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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

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@xxxxxxxx>
> ---
> 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