When Entrysign has been mitigated in firwmare, it is believed to be safe to
rely on the CPU patchloader again.  This avoids us needing to maintain the
digest table for all new microcode indefinitely.

Relax the digest check when firmware looks to be up to date, and leave behind
a clear message when not.

This is best-effort only.  If a malicious microcode has been loaded prior to
Xen running, then all bets are off.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>

v2:
 * Corrections to the revision table.
 * Updates to various comments.
 * Add a "WARNING: " prefix to the message about vulnerability
---
 xen/arch/x86/cpu/microcode/amd.c     | 86 +++++++++++++++++++++++++++-
 xen/arch/x86/cpu/microcode/core.c    |  2 +
 xen/arch/x86/cpu/microcode/private.h |  2 +
 3 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index f331d9dfee6e..9ecf6c37d3f4 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -101,6 +101,7 @@ static const struct patch_digest {
 } patch_digests[] = {
 #include "amd-patch-digests.c"
 };
+static bool __ro_after_init entrysign_mitigiated_in_firmware;
 
 static int cf_check cmp_patch_id(const void *key, const void *elem)
 {
@@ -122,11 +123,11 @@ static bool check_digest(const struct container_microcode *mc)
 
     /*
      * Zen1 thru Zen5 CPUs are known to use a weak signature algorithm on
-     * microcode updates.  Mitigate by checking the digest of the patch
-     * against a list of known provenance.
+     * microcode updates.  If this has not been mitigated in firmware,
+     * checking the digest of the patch against a list of known provenance.
      */
     if ( boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a ||
-         !opt_digest_check )
+         entrysign_mitigiated_in_firmware || !opt_digest_check )
         return true;
 
     pd = bsearch(&patch->patch_id, patch_digests, ARRAY_SIZE(patch_digests),
@@ -603,3 +604,82 @@ static void __init __constructor test_digests_sorted(void)
     }
 }
 #endif /* CONFIG_SELF_TESTS */
+
+/*
+ * The Entrysign vulnerability affects all Zen1 thru Zen5 CPUs.  Firmware
+ * fixes were produced from Nov 2024.  Zen3 thru Zen5 can continue to take
+ * OS-loadable microcode updates using a new signature scheme, as long as
+ * firmware has been updated first.
+ */
+void __init amd_check_entrysign(void)
+{
+    unsigned int curr_rev;
+    uint8_t fixed_rev;
+
+    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||
+         boot_cpu_data.family < 0x17 ||
+         boot_cpu_data.family > 0x1a )
+        return;
+
+    /*
+     * Table taken from Linux, which is the only known source of information
+     * about client revisions.  Note, Linux expresses "last-vulnerable-rev"
+     * while Xen wants "first-fixed-rev".
+     */
+    curr_rev = this_cpu(cpu_sig).rev;
+    switch ( curr_rev >> 8 )
+    {
+    case 0x080012: fixed_rev = 0x78; break;
+    case 0x080082: fixed_rev = 0x10; break;
+    case 0x083010: fixed_rev = 0x7d; break;
+    case 0x086001: fixed_rev = 0x0f; break;
+    case 0x086081: fixed_rev = 0x09; break;
+    case 0x087010: fixed_rev = 0x35; break;
+    case 0x08a000: fixed_rev = 0x0b; break;
+    case 0x0a0010: fixed_rev = 0x7b; break;
+    case 0x0a0011: fixed_rev = 0xdb; break;
+    case 0x0a0012: fixed_rev = 0x44; break;
+    case 0x0a0082: fixed_rev = 0x0f; break;
+    case 0x0a1011: fixed_rev = 0x54; break;
+    case 0x0a1012: fixed_rev = 0x4f; break;
+    case 0x0a1081: fixed_rev = 0x0a; break;
+    case 0x0a2010: fixed_rev = 0x30; break;
+    case 0x0a2012: fixed_rev = 0x13; break;
+    case 0x0a4041: fixed_rev = 0x0a; break;
+    case 0x0a5000: fixed_rev = 0x14; break;
+    case 0x0a6012: fixed_rev = 0x0b; break;
+    case 0x0a7041: fixed_rev = 0x0a; break;
+    case 0x0a7052: fixed_rev = 0x09; break;
+    case 0x0a7080: fixed_rev = 0x0a; break;
+    case 0x0a70c0: fixed_rev = 0x0a; break;
+    case 0x0aa001: fixed_rev = 0x17; break;
+    case 0x0aa002: fixed_rev = 0x19; break;
+    case 0x0b0021: fixed_rev = 0x47; break;
+    case 0x0b1010: fixed_rev = 0x47; break;
+    case 0x0b2040: fixed_rev = 0x32; break;
+    case 0x0b4040: fixed_rev = 0x32; break;
+    case 0x0b6000: fixed_rev = 0x32; break;
+    case 0x0b7000: fixed_rev = 0x32; break;
+    default:
+        printk(XENLOG_WARNING
+               "Unrecognised CPU %02x-%02x-%02x ucode 0x%08x, assuming vulnerable to Entrysign\n",
+               boot_cpu_data.family, boot_cpu_data.model,
+               boot_cpu_data.stepping, curr_rev);
+        return;
+    }
+
+    /*
+     * This check is best-effort.  If the platform looks to be out of date, it
+     * probably is.  If the platform looks to be fixed, it either genuinely
+     * is, or malware has gotten in before Xen booted and all bets are off.
+     */
+    if ( (uint8_t)curr_rev >= fixed_rev )
+    {
+        entrysign_mitigiated_in_firmware = true;
+        return;
+    }
+
+    printk(XENLOG_WARNING
+           "WARNING: Platform vulnerable to Entrysign (SB-7033, CVE-2024-36347) - firmware update required\n");
+    add_taint(TAINT_CPU_OUT_OF_SPEC);
+}
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 2705bb43c97f..1d1a5aa4b097 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -750,6 +750,8 @@ static int __init early_microcode_load(struct boot_info *bi)
     int idx = opt_mod_idx;
     int rc;
 
+    amd_check_entrysign();
+
     /*
      * Cmdline parsing ensures this invariant holds, so that we don't end up
      * trying to mix multiple ways of finding the microcode.
diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h
index f5e2bfee00d9..e6c965dc99dd 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -81,8 +81,10 @@ extern bool opt_digest_check;
  */
 #ifdef CONFIG_AMD
 void ucode_probe_amd(struct microcode_ops *ops);
+void amd_check_entrysign(void);
 #else
 static inline void ucode_probe_amd(struct microcode_ops *ops) {}
+static inline void amd_check_entrysign(void) {}
 #endif
 
 #ifdef CONFIG_INTEL
-- 
2.39.5

On 27.10.2025 23:17, Andrew Cooper wrote:
> When Entrysign has been mitigated in firwmare, it is believed to be safe to
> rely on the CPU patchloader again.  This avoids us needing to maintain the
> digest table for all new microcode indefinitely.
> 
> Relax the digest check when firmware looks to be up to date, and leave behind
> a clear message when not.
> 
> This is best-effort only.  If a malicious microcode has been loaded prior to
> Xen running, then all bets are off.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Like for patch 4, adjustments for Zen6 are then going to be needed here too,
aiui. May be worth repeating that statement here.

> @@ -603,3 +604,82 @@ static void __init __constructor test_digests_sorted(void)
>      }
>  }
>  #endif /* CONFIG_SELF_TESTS */
> +
> +/*
> + * The Entrysign vulnerability affects all Zen1 thru Zen5 CPUs.  Firmware
> + * fixes were produced from Nov 2024.  Zen3 thru Zen5 can continue to take
> + * OS-loadable microcode updates using a new signature scheme, as long as
> + * firmware has been updated first.
> + */
> +void __init amd_check_entrysign(void)
> +{
> +    unsigned int curr_rev;
> +    uint8_t fixed_rev;
> +
> +    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||

Given the function name, might this check better live at the call site?

> +         boot_cpu_data.family < 0x17 ||
> +         boot_cpu_data.family > 0x1a )
> +        return;
> +
> +    /*
> +     * Table taken from Linux, which is the only known source of information
> +     * about client revisions.  Note, Linux expresses "last-vulnerable-rev"
> +     * while Xen wants "first-fixed-rev".
> +     */
> +    curr_rev = this_cpu(cpu_sig).rev;
> +    switch ( curr_rev >> 8 )
> +    {
> +    case 0x080012: fixed_rev = 0x78; break;
> +    case 0x080082: fixed_rev = 0x10; break;
> +    case 0x083010: fixed_rev = 0x7d; break;
> +    case 0x086001: fixed_rev = 0x0f; break;
> +    case 0x086081: fixed_rev = 0x09; break;
> +    case 0x087010: fixed_rev = 0x35; break;
> +    case 0x08a000: fixed_rev = 0x0b; break;
> +    case 0x0a0010: fixed_rev = 0x7b; break;
> +    case 0x0a0011: fixed_rev = 0xdb; break;
> +    case 0x0a0012: fixed_rev = 0x44; break;
> +    case 0x0a0082: fixed_rev = 0x0f; break;
> +    case 0x0a1011: fixed_rev = 0x54; break;
> +    case 0x0a1012: fixed_rev = 0x4f; break;
> +    case 0x0a1081: fixed_rev = 0x0a; break;
> +    case 0x0a2010: fixed_rev = 0x30; break;
> +    case 0x0a2012: fixed_rev = 0x13; break;
> +    case 0x0a4041: fixed_rev = 0x0a; break;
> +    case 0x0a5000: fixed_rev = 0x14; break;
> +    case 0x0a6012: fixed_rev = 0x0b; break;
> +    case 0x0a7041: fixed_rev = 0x0a; break;
> +    case 0x0a7052: fixed_rev = 0x09; break;
> +    case 0x0a7080: fixed_rev = 0x0a; break;
> +    case 0x0a70c0: fixed_rev = 0x0a; break;
> +    case 0x0aa001: fixed_rev = 0x17; break;
> +    case 0x0aa002: fixed_rev = 0x19; break;
> +    case 0x0b0021: fixed_rev = 0x47; break;
> +    case 0x0b1010: fixed_rev = 0x47; break;
> +    case 0x0b2040: fixed_rev = 0x32; break;
> +    case 0x0b4040: fixed_rev = 0x32; break;
> +    case 0x0b6000: fixed_rev = 0x32; break;
> +    case 0x0b7000: fixed_rev = 0x32; break;

Acked-by: Jan Beulich <jbeulich@suse.com>
(after cross checking with up-to-date Linux, i.e. including your recent
correction there)

Jan

On 28/10/2025 9:47 am, Jan Beulich wrote:
> On 27.10.2025 23:17, Andrew Cooper wrote:
>> When Entrysign has been mitigated in firwmare, it is believed to be safe to
>> rely on the CPU patchloader again.  This avoids us needing to maintain the
>> digest table for all new microcode indefinitely.
>>
>> Relax the digest check when firmware looks to be up to date, and leave behind
>> a clear message when not.
>>
>> This is best-effort only.  If a malicious microcode has been loaded prior to
>> Xen running, then all bets are off.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Like for patch 4, adjustments for Zen6 are then going to be needed here too,
> aiui. May be worth repeating that statement here.

Ok.

>
>> @@ -603,3 +604,82 @@ static void __init __constructor test_digests_sorted(void)
>>      }
>>  }
>>  #endif /* CONFIG_SELF_TESTS */
>> +
>> +/*
>> + * The Entrysign vulnerability affects all Zen1 thru Zen5 CPUs.  Firmware
>> + * fixes were produced from Nov 2024.  Zen3 thru Zen5 can continue to take
>> + * OS-loadable microcode updates using a new signature scheme, as long as
>> + * firmware has been updated first.
>> + */
>> +void __init amd_check_entrysign(void)
>> +{
>> +    unsigned int curr_rev;
>> +    uint8_t fixed_rev;
>> +
>> +    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||
> Given the function name, might this check better live at the call site?

Possibly, but I really don't want to split the vendor check away from
the family ranges.

A family check without a vendor check in eyeshot is
suspicious-going-on-buggy, and this is called once at init.

>
>> +         boot_cpu_data.family < 0x17 ||
>> +         boot_cpu_data.family > 0x1a )
>> +        return;
>> +
>> +    /*
>> +     * Table taken from Linux, which is the only known source of information
>> +     * about client revisions.  Note, Linux expresses "last-vulnerable-rev"
>> +     * while Xen wants "first-fixed-rev".
>> +     */
>> +    curr_rev = this_cpu(cpu_sig).rev;
>> +    switch ( curr_rev >> 8 )
>> +    {
>> +    case 0x080012: fixed_rev = 0x78; break;
>> +    case 0x080082: fixed_rev = 0x10; break;
>> +    case 0x083010: fixed_rev = 0x7d; break;
>> +    case 0x086001: fixed_rev = 0x0f; break;
>> +    case 0x086081: fixed_rev = 0x09; break;
>> +    case 0x087010: fixed_rev = 0x35; break;
>> +    case 0x08a000: fixed_rev = 0x0b; break;
>> +    case 0x0a0010: fixed_rev = 0x7b; break;
>> +    case 0x0a0011: fixed_rev = 0xdb; break;
>> +    case 0x0a0012: fixed_rev = 0x44; break;
>> +    case 0x0a0082: fixed_rev = 0x0f; break;
>> +    case 0x0a1011: fixed_rev = 0x54; break;
>> +    case 0x0a1012: fixed_rev = 0x4f; break;
>> +    case 0x0a1081: fixed_rev = 0x0a; break;
>> +    case 0x0a2010: fixed_rev = 0x30; break;
>> +    case 0x0a2012: fixed_rev = 0x13; break;
>> +    case 0x0a4041: fixed_rev = 0x0a; break;
>> +    case 0x0a5000: fixed_rev = 0x14; break;
>> +    case 0x0a6012: fixed_rev = 0x0b; break;
>> +    case 0x0a7041: fixed_rev = 0x0a; break;
>> +    case 0x0a7052: fixed_rev = 0x09; break;
>> +    case 0x0a7080: fixed_rev = 0x0a; break;
>> +    case 0x0a70c0: fixed_rev = 0x0a; break;
>> +    case 0x0aa001: fixed_rev = 0x17; break;
>> +    case 0x0aa002: fixed_rev = 0x19; break;
>> +    case 0x0b0021: fixed_rev = 0x47; break;
>> +    case 0x0b1010: fixed_rev = 0x47; break;
>> +    case 0x0b2040: fixed_rev = 0x32; break;
>> +    case 0x0b4040: fixed_rev = 0x32; break;
>> +    case 0x0b6000: fixed_rev = 0x32; break;
>> +    case 0x0b7000: fixed_rev = 0x32; break;
> Acked-by: Jan Beulich <jbeulich@suse.com>
> (after cross checking with up-to-date Linux, i.e. including your recent
> correction there)

Thanks.

~Andrew

On 28.10.2025 12:31, Andrew Cooper wrote:
> On 28/10/2025 9:47 am, Jan Beulich wrote:
>> On 27.10.2025 23:17, Andrew Cooper wrote:
>>> @@ -603,3 +604,82 @@ static void __init __constructor test_digests_sorted(void)
>>>      }
>>>  }
>>>  #endif /* CONFIG_SELF_TESTS */
>>> +
>>> +/*
>>> + * The Entrysign vulnerability affects all Zen1 thru Zen5 CPUs.  Firmware
>>> + * fixes were produced from Nov 2024.  Zen3 thru Zen5 can continue to take
>>> + * OS-loadable microcode updates using a new signature scheme, as long as
>>> + * firmware has been updated first.
>>> + */
>>> +void __init amd_check_entrysign(void)
>>> +{
>>> +    unsigned int curr_rev;
>>> +    uint8_t fixed_rev;
>>> +
>>> +    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||
>> Given the function name, might this check better live at the call site?
> 
> Possibly, but I really don't want to split the vendor check away from
> the family ranges.
> 
> A family check without a vendor check in eyeshot is
> suspicious-going-on-buggy, and this is called once at init.

Well, okay, I'm certainly not going to insist. It merely occurred to me that
normally we would call amd_*() functions only once we know we run on AMD (or
sometimes Hygon) hardware.

Jan