-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2025-54518 / XSA-490
x86: CPU Opcode Cache corruption
ISSUE DESCRIPTION
=================
AMD have disclosed a potential vulnerability in certain CPUs which can
cause instructions to execute at a higher privilege.
For more information, see:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html
IMPACT
======
Code of any privilege could escalate to a higher privilege, including
userspace to kernel, and guest to host.
VULNERABLE SYSTEMS
==================
Systems running all versions of Xen are affected.
Only AMD Fam17h CPUs (Zen2 microarchitecture) are believed to be
vulnerable. Other AMD CPUs and CPUs from other manufacturers are not
known to be affected.
MITIGATION
==========
There are no mitigations.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
For Xen 4.17, patch 1 is a backport of a change which only went back as
far as 4.18 under normal bugfix rules, but which is tightly texturally
coupled with the XSA-940 fix. It is possible to rework patch 2 to avoid
patch 1, but a number of Xen-focused downstreams already have patch 1
backported, and those without patch 1 really ought to take it. So,
while this is slightly abnormal for an XSA, it is believed to be in the
best interest of everyone with a 4.17 based Xen.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa490.patch xen-unstable
xsa490-4.21.patch Xen 4.21.x - Xen 4.18.x
xsa490-4.17-?.patch Xen 4.17.x
$ sha256sum xsa490*
7c256d3384bf640d171ae2f18930c193a72bbdd92ebeb8942e58634dd7b27439 xsa490.patch
4d64d95937630f2147bb69d0d0ff24fc7d97efd48e376d882265662f93886ec7 xsa490-4.17-1.patch
6c717a5bd914088463c74b89893672388848a2222165478aed63b6c2a4151e28 xsa490-4.17-2.patch
1e397550a542bc0957bf93a6e6f01ffcdfe8f005697a505c62ec6120a72d3f90 xsa490-4.21.patch
$
-----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmoDTuQMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZn38H/2xujQ3YDEsE2U8RiH/6M1yVxnATlCEqEPBxIcVX
h6W4QMzlFw/IXZBi6twduuzMME2uX6eKWCbE9riw2v4lybgNYMxV20oW86LhjLwr
uL1NHJ3Fop1IuRy+po20jmT9sPfpieHU9zGmFvgd/k91gSZ1b/5G8k36MtgODL0j
4Svsdo3LYSvULQn5EymjO/t57ZZIDBWj5Od7aBbPuGkQKtW6+/UCE0JnrzOtP+Di
0Y5bBSUhwrMh0h32AV/w2nwvFQN/EeyakfjDWQc1ST6wHzFMLSo2kaY40TZ6C+T8
RnN646ouPizmiSDu2G/dMrLJ5kc3PFqQvN3JRI4dyf075yg=
=Dclq
-----END PGP SIGNATURE-----
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/amd: Mitigate AMD-SN-7052
This is XSA-490 / CVE-2025-54518.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 712734a6e723..70783c9a0af0 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1015,11 +1015,25 @@ static void amd_check_bp_cfg(void)
{
uint64_t val, new = 0;
- /*
- * AMD Erratum #1485. Set bit 5, as instructed.
- */
- if (!cpu_has_hypervisor && boot_cpu_data.family == 0x19 && is_zen4_uarch())
- new |= (1 << 5);
+ if (!cpu_has_hypervisor) {
+ /*
+ * AMD Erratum #1485. If SMT is enabled and STIBP disabled,
+ * the CPU may fetch incorrect instruction bytes.
+ *
+ * Set bit 5, as instructed.
+ */
+ if (boot_cpu_data.family == 0x19 && is_zen4_uarch())
+ new |= (1 << 5);
+
+ /*
+ * AMD SB-7052. CPU OP Cache corruption, causing instructions
+ * to be executed at a higher privilege.
+ *
+ * Set bit 33, as instructed.
+ */
+ if (boot_cpu_data.family == 0x17 && is_zen2_uarch())
+ new |= (1UL << 33);
+ }
/*
* On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Support for SRSO_U/S_NO and SRSO_MSR_FIX
AMD have updated the SRSO whitepaper[1] with further information. These
features exist on AMD Zen5 CPUs and are necessary for Xen to use.
The two features are in principle unrelated:
* SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
User(CPL3) / Supervisor(CPL<3) boundary. i.e. Xen don't need to use
IBPB-on-entry for PV64. PV32 guests are explicitly unsupported for
speculative issues, and excluded from consideration for simplicity.
* SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
available in MSR_BP_CFG. When set, SRSO attacks can't cross the host/guest
boundary. i.e. Xen don't need to use IBPB-on-entry for HVM.
Extend ibpb_calculations() to account for these when calculating
opt_ibpb_entry_{pv,hvm} defaults. Add a `bp-spec-reduce=<bool>` option to
control the use of BP_SPEC_REDUCE, with it active by default.
Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
once.
Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
to skip SRSO mitigations too:
* This is trivial for HVM guests. It is also is accurate for PV32 guests
too, but we have already excluded them from consideration, and do so again
here to simplify the policy logic.
* As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
However, after discussing with AMD, an implementation detail of having
BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
guests when the BP_SPEC_REDUCE precondition is met.
Finally, fix a typo in the SRSO_NO's comment.
[1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit a1746cd4434dd27ca2da8430dfb10edc76264bb3)
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 4f2907eb67f2..ad8027732665 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2330,7 +2330,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> {ibrs,ibpb,ssbd,psfd,
> eager-fpu,l1d-flush,branch-harden,srb-lock,
> unpriv-mmio,gds-mit,div-scrub,lock-harden,
-> bhi-dis-s}=<bool> ]`
+> bhi-dis-s,bp-spec-reduce}=<bool> ]`
Controls for speculative execution sidechannel mitigations. By default, Xen
will pick the most appropriate mitigations based on compiled in support,
@@ -2479,6 +2479,13 @@ boolean can be used to force or prevent Xen from using speculation barriers to
protect lock critical regions. This mitigation won't be engaged by default,
and needs to be explicitly enabled on the command line.
+On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
+to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
+SRSO (Speculative Return Stack Overflow) vulnerability. Xen will use
+bp-spec-reduce when available, as it is preferable to using `ibpb-entry=hvm`
+to mitigate SRSO for HVM guests, and because it is a prerequisite to advertise
+SRSO_U/S_NO to PV guests.
+
### sync_console
> `= <boolean>`
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index f259c77435ea..9224c36d81b5 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -14,6 +14,7 @@
#include <asm/msr-index.h>
#include <asm/paging.h>
#include <asm/setup.h>
+#include <asm/spec_ctrl.h>
#include <asm/xstate.h>
struct cpu_policy __ro_after_init raw_cpu_policy;
@@ -650,6 +651,26 @@ static void __init calculate_pv_max_policy(void)
__clear_bit(X86_FEATURE_IBRS, fs);
}
+ /*
+ * SRSO_U/S_NO means that the CPU is not vulnerable to SRSO attacks across
+ * the User (CPL3) / Supervisor (CPL<3) boundary.
+ *
+ * PV32 guests are unsupported for speculative issues, and excluded from
+ * consideration for simplicity.
+ *
+ * The PV64 user/kernel boundary is CPL3 on both sides, so SRSO_U/S_NO
+ * won't convey the meaning that a PV kernel expects.
+ *
+ * After discussions with AMD, an implementation detail of having
+ * BP_SPEC_REDUCE active causes the PV64 user/kernel boundary to have a
+ * property compatible with the meaning of SRSO_U/S_NO.
+ *
+ * If BP_SPEC_REDUCE isn't active, remove SRSO_U/S_NO from the PV max
+ * policy, which will cause it to filter out of PV default too.
+ */
+ if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+ __clear_bit(X86_FEATURE_SRSO_US_NO, fs);
+
guest_common_max_feature_adjustments(fs);
guest_common_feature_adjustments(fs);
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 3312d896dd90..8c4e50de4536 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1018,16 +1018,33 @@ static void amd_init_fp_cfg(const struct cpuinfo_x86 *c)
wrmsrl(MSR_AMD64_FP_CFG, val | new);
}
-static void amd_check_erratum_1485(void)
+static void amd_check_bp_cfg(void)
{
- uint64_t val, chickenbit = (1 << 5);
+ uint64_t val, new = 0;
- if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
+ /*
+ * AMD Erratum #1485. Set bit 5, as instructed.
+ */
+ if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+ new |= (1 << 5);
+
+ /*
+ * On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
+ * default. This lets us do two things:
+ *
+ * 1) Avoid IBPB-on-entry to mitigate SRSO attacks from HVM guests.
+ * 2) Advertise SRSO_US_NO to PV guests.
+ */
+ if (boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) && opt_bp_spec_reduce)
+ new |= BP_CFG_SPEC_REDUCE;
+
+ /* Avoid reading BP_CFG if we don't intend to change anything. */
+ if (!new)
return;
rdmsrl(MSR_AMD64_BP_CFG, val);
- if (val & chickenbit)
+ if ((val & new) == new)
return;
/*
@@ -1036,7 +1053,7 @@ static void amd_check_erratum_1485(void)
* same time before the chickenbit is set. It's benign because the
* value being written is the same on both.
*/
- wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit);
+ wrmsrl(MSR_AMD64_BP_CFG, val | new);
}
static void cf_check init_amd(struct cpuinfo_x86 *c)
@@ -1314,7 +1331,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
disable_c1_ramping();
amd_check_zenbleed();
- amd_check_erratum_1485();
+ amd_check_bp_cfg();
if (fam17_c6_disabled)
fam17_disable_c6(NULL);
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index bed0ab7b213c..db3db08a54a0 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -391,6 +391,7 @@
#define AMD64_DE_CFG_LFENCE_SERIALISE (_AC(1, ULL) << 1)
#define MSR_AMD64_EX_CFG 0xc001102c
#define MSR_AMD64_BP_CFG 0xc001102e
+#define BP_CFG_SPEC_REDUCE (_AC(1, ULL) << 4)
#define MSR_AMD64_DE_CFG2 0xc00110e3
#define MSR_AMD64_DR0_ADDRESS_MASK 0xc0011027
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index 60844b755dff..b7349ac89852 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -102,6 +102,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
extern bool cpu_has_bug_l1tf;
extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
+extern bool opt_bp_spec_reduce;
/*
* The L1D address mask, which might be wider than reported in CPUID, and the
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 5005f0acdde9..b71fe0a4ece1 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -95,6 +95,7 @@ static bool __initdata opt_unpriv_mmio;
static bool __ro_after_init opt_verw_mmio;
static int8_t __initdata opt_gds_mit = -1;
static int8_t __initdata opt_div_scrub = -1;
+bool __ro_after_init opt_bp_spec_reduce = true;
static int __init cf_check parse_spec_ctrl(const char *s)
{
@@ -155,6 +156,7 @@ static int __init cf_check parse_spec_ctrl(const char *s)
opt_unpriv_mmio = false;
opt_gds_mit = 0;
opt_div_scrub = 0;
+ opt_bp_spec_reduce = false;
}
else if ( val > 0 )
rc = -EINVAL;
@@ -375,6 +377,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
opt_gds_mit = val;
else if ( (val = parse_boolean("div-scrub", s, ss)) >= 0 )
opt_div_scrub = val;
+ else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
+ opt_bp_spec_reduce = val;
else
rc = -EINVAL;
@@ -517,7 +521,7 @@ static void __init print_details(enum ind_thunk thunk)
* Hardware read-only information, stating immunity to certain issues, or
* suggestions of which mitigation to use.
*/
- printk(" Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ printk(" Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
(caps & ARCH_CAPS_RDCL_NO) ? " RDCL_NO" : "",
(caps & ARCH_CAPS_EIBRS) ? " EIBRS" : "",
(caps & ARCH_CAPS_RSBA) ? " RSBA" : "",
@@ -542,11 +546,12 @@ static void __init print_details(enum ind_thunk thunk)
(e8b & cpufeat_mask(X86_FEATURE_IBPB_RET)) ? " IBPB_RET" : "",
(e21a & cpufeat_mask(X86_FEATURE_IBPB_BRTYPE)) ? " IBPB_BRTYPE" : "",
(e21a & cpufeat_mask(X86_FEATURE_SRSO_NO)) ? " SRSO_NO" : "",
+ (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO)) ? " SRSO_US_NO" : "",
(e21c & cpufeat_mask(X86_FEATURE_TSA_SQ_NO)) ? " TSA_SQ_NO" : "",
(e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO)) ? " TSA_L1_NO" : "");
/* Hardware features which need driving to mitigate issues. */
- printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
(e8b & cpufeat_mask(X86_FEATURE_IBPB)) ||
(_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBPB" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS)) ||
@@ -566,6 +571,7 @@ static void __init print_details(enum ind_thunk thunk)
(caps & ARCH_CAPS_GDS_CTRL) ? " GDS_CTRL" : "",
(caps & ARCH_CAPS_RFDS_CLEAR) ? " RFDS_CLEAR" : "",
(e21a & cpufeat_mask(X86_FEATURE_SBPB)) ? " SBPB" : "",
+ (e21a & cpufeat_mask(X86_FEATURE_SRSO_MSR_FIX)) ? " SRSO_MSR_FIX" : "",
(e21a & cpufeat_mask(X86_FEATURE_VERW_CLEAR)) ? " VERW_CLEAR" : "");
/* Compiled-in support which pertains to mitigations. */
@@ -1138,7 +1144,7 @@ static void __init div_calculations(bool hw_smt_enabled)
static void __init ibpb_calculations(void)
{
- bool def_ibpb_entry = false;
+ bool def_ibpb_entry_pv = false, def_ibpb_entry_hvm = false;
/* Check we have hardware IBPB support before using it... */
if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
@@ -1163,22 +1169,43 @@ static void __init ibpb_calculations(void)
* Confusion. Mitigate with IBPB-on-entry.
*/
if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
- def_ibpb_entry = true;
+ def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
/*
- * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
- * Overflow in most configurations. Mitigate with IBPB-on-entry if we
- * have the microcode that makes this an effective option.
+ * In addition to BTC, Zen3 and later CPUs suffer from Speculative
+ * Return Stack Overflow in most configurations. If we have microcode
+ * that makes IBPB-on-entry an effective mitigation, see about using
+ * it.
*/
if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
- def_ibpb_entry = true;
+ {
+ /*
+ * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
+ * possible across the User (CPL3) / Supervisor (CPL<3) boundary.
+ *
+ * Ignoring PV32 (not security supported for speculative issues),
+ * this means we only need to use IBPB-on-entry for PV guests on
+ * hardware which doesn't enumerate SRSO_US_NO.
+ */
+ if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
+ def_ibpb_entry_pv = true;
+
+ /*
+ * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_REDUCE
+ * to mitigate SRSO across the host/guest boundary. We only need
+ * to use IBPB-on-entry for HVM guests if we haven't enabled this
+ * control.
+ */
+ if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+ def_ibpb_entry_hvm = true;
+ }
}
if ( opt_ibpb_entry_pv == -1 )
- opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry;
+ opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv;
if ( opt_ibpb_entry_hvm == -1 )
- opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry;
+ opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hvm;
if ( opt_ibpb_entry_pv )
{
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 42db132b4c2f..12ca3efc5ce9 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -289,7 +289,9 @@ XEN_CPUFEATURE(NSCB, 11*32+ 6) /*A Null Selector Clears Base (and
XEN_CPUFEATURE(AUTO_IBRS, 11*32+ 8) /* Automatic IBRS */
XEN_CPUFEATURE(SBPB, 11*32+27) /*A Selective Branch Predictor Barrier */
XEN_CPUFEATURE(IBPB_BRTYPE, 11*32+28) /*A IBPB flushes Branch Type predictions too */
-XEN_CPUFEATURE(SRSO_NO, 11*32+29) /*A Hardware not vulenrable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_NO, 11*32+29) /*A Hardware not vulnerable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_US_NO, 11*32+30) /*A! Hardware not vulnerable to SRSO across the User/Supervisor boundary */
+XEN_CPUFEATURE(SRSO_MSR_FIX, 11*32+31) /* MSR_BP_CFG.BP_SPEC_REDUCE available */
/* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */
XEN_CPUFEATURE(INTEL_PPIN, 12*32+ 0) /* Protected Processor Inventory Number */
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/amd: Mitigate AMD-SN-7052
This is XSA-490 / CVE-2025-54518.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 8c4e50de4536..86268e8619b7 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1022,11 +1022,25 @@ static void amd_check_bp_cfg(void)
{
uint64_t val, new = 0;
- /*
- * AMD Erratum #1485. Set bit 5, as instructed.
- */
- if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
- new |= (1 << 5);
+ if (!cpu_has_hypervisor) {
+ /*
+ * AMD Erratum #1485. If SMT is enabled and STIBP disabled,
+ * the CPU may fetch incorrect instruction bytes.
+ *
+ * Set bit 5, as instructed.
+ */
+ if (boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+ new |= (1 << 5);
+
+ /*
+ * AMD SB-7052. CPU OP Cache corruption, causing instructions
+ * to be executed at a higher privilege.
+ *
+ * Set bit 33, as instructed.
+ */
+ if (boot_cpu_data.x86 == 0x17 && is_zen2_uarch())
+ new |= (1UL << 33);
+ }
/*
* On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/amd: Mitigate AMD-SN-7052
This is XSA-490 / CVE-2025-54518.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 1bb0766ebf13..b5bf2b732e8f 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1116,11 +1116,25 @@ static void amd_check_bp_cfg(void)
{
uint64_t val, new = 0;
- /*
- * AMD Erratum #1485. Set bit 5, as instructed.
- */
- if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
- new |= (1 << 5);
+ if (!cpu_has_hypervisor) {
+ /*
+ * AMD Erratum #1485. If SMT is enabled and STIBP disabled,
+ * the CPU may fetch incorrect instruction bytes.
+ *
+ * Set bit 5, as instructed.
+ */
+ if (boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+ new |= (1 << 5);
+
+ /*
+ * AMD SB-7052. CPU OP Cache corruption, causing instructions
+ * to be executed at a higher privilege.
+ *
+ * Set bit 33, as instructed.
+ */
+ if (boot_cpu_data.x86 == 0x17 && is_zen2_uarch())
+ new |= (1UL << 33);
+ }
/*
* On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
© 2016 - 2026 Red Hat, Inc.