From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH 5/5] x86/ucode: Relax digest check when Entrysign is fixed in firmware
Date: Mon, 20 Oct 2025 14:19:55 +0100 [thread overview]
Message-ID: <20251020131955.2928261-6-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <20251020131955.2928261-1-andrew.cooper3@citrix.com>
When Entrysign has been mitigated in firwmare, it is believed to be safe to
pass blobs to the CPU again. This avoids us needing to update the digest
table for new microcodes.
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>
I need to double check the revision table. I think I need to submit a
correction to Linux first.
---
xen/arch/x86/cpu/microcode/amd.c | 81 +++++++++++++++++++++++++++-
xen/arch/x86/cpu/microcode/core.c | 2 +
xen/arch/x86/cpu/microcode/private.h | 2 +
3 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 30bddc89da0a..b5b55b7a00cd 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)
{
@@ -125,7 +126,7 @@ static bool check_digest(const struct container_microcode *mc)
* microcode updates. Mitigate by checking the digest of the patch
* against a list of known provenance.
*/
- if ( boot_cpu_data.family < 0x17 ||
+ if ( boot_cpu_data.family < 0x17 || entrysign_mitigiated_in_firmware ||
!opt_digest_check )
return true;
@@ -597,3 +598,81 @@ 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 in Nov/Dec 2025. 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.
+ */
+ curr_rev = this_cpu(cpu_sig).rev;
+ switch ( curr_rev >> 8 )
+ {
+ case 0x080012: fixed_rev = 0x6f; break;
+ case 0x080082: fixed_rev = 0x0f; break;
+ case 0x083010: fixed_rev = 0x7c; break;
+ case 0x086001: fixed_rev = 0x0e; break;
+ case 0x086081: fixed_rev = 0x08; break;
+ case 0x087010: fixed_rev = 0x34; break;
+ case 0x08a000: fixed_rev = 0x0a; break;
+ case 0x0a0010: fixed_rev = 0x7a; break;
+ case 0x0a0011: fixed_rev = 0xda; break;
+ case 0x0a0012: fixed_rev = 0x43; break;
+ case 0x0a0082: fixed_rev = 0x0e; break;
+ case 0x0a1011: fixed_rev = 0x53; break;
+ case 0x0a1012: fixed_rev = 0x4e; break;
+ case 0x0a1081: fixed_rev = 0x09; break;
+ case 0x0a2010: fixed_rev = 0x2f; break;
+ case 0x0a2012: fixed_rev = 0x12; break;
+ case 0x0a4041: fixed_rev = 0x09; break;
+ case 0x0a5000: fixed_rev = 0x13; break;
+ case 0x0a6012: fixed_rev = 0x0a; break;
+ case 0x0a7041: fixed_rev = 0x09; break;
+ case 0x0a7052: fixed_rev = 0x08; break;
+ case 0x0a7080: fixed_rev = 0x09; break;
+ case 0x0a70c0: fixed_rev = 0x09; break;
+ case 0x0aa001: fixed_rev = 0x16; break;
+ case 0x0aa002: fixed_rev = 0x18; break;
+ case 0x0b0021: fixed_rev = 0x46; break;
+ case 0x0b1010: fixed_rev = 0x46; break;
+ case 0x0b2040: fixed_rev = 0x31; break;
+ case 0x0b4040: fixed_rev = 0x31; break;
+ case 0x0b6000: fixed_rev = 0x31; break;
+ case 0x0b7000: fixed_rev = 0x31; 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_ERR
+ "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
next prev parent reply other threads:[~2025-10-20 13:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 13:19 [PATCH for-4.21? 0/5] x86/ucode: Support loading latest ucode from linux-firwmare Andrew Cooper
2025-10-20 13:19 ` [PATCH 1/5] x86/ucode: Fix missing printk() newline in ucode_probe_amd() Andrew Cooper
2025-10-20 13:37 ` Jan Beulich
2025-10-20 15:02 ` Andrew Cooper
2025-10-20 13:19 ` [PATCH 2/5] x86/ucode: Abort parallel load early on any control thread error Andrew Cooper
2025-10-20 15:55 ` Jan Beulich
2025-10-22 19:28 ` Andrew Cooper
2025-10-23 6:24 ` Jan Beulich
2025-10-27 22:46 ` Andrew Cooper
2025-10-28 8:07 ` Jan Beulich
2025-10-20 13:19 ` [PATCH 3/5] x86/ucode: Refine TLB flush fix for AMD Fam17h CPUs Andrew Cooper
2025-10-21 8:34 ` Jan Beulich
2025-10-20 13:19 ` [PATCH 4/5] x86/ucode: Cross check the minimum revision Andrew Cooper
2025-10-21 9:18 ` Jan Beulich
2025-10-21 9:24 ` Andrew Cooper
2025-10-20 13:19 ` Andrew Cooper [this message]
2025-10-20 15:06 ` [PATCH 5/5] x86/ucode: Relax digest check when Entrysign is fixed in firmware Andrew Cooper
2025-10-21 9:47 ` Jan Beulich
2025-10-22 21:19 ` Andrew Cooper
2025-10-23 7:05 ` Jan Beulich
2025-10-27 21:42 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251020131955.2928261-6-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).