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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.
+                */
+               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);