[PATCH v5 0/8] Add SEV-SNP BTB Isolation and IBPB-on-Entry guest features

[PATCH v5 0/8] Add SEV-SNP BTB Isolation and IBPB-on-Entry guest features

[Kim Phillips]

This series advertises two SEV-SNP guest-selectable side-channel
protections through KVM's vmsa_features ABI -- BTB Isolation
(SEV_FEATURES bit 7) and IBPB-on-Entry (SEV_FEATURES bit 21) -- along
with SVM_SEV_FEAT_SNP_ACTIVE, and fixes two x86 mitigation-selection
bugs that stand in the way.

The cpu/bugs patches come first because they are prerequisites, not
drive-by cleanups:

  - Patch 1 fixes spectre_v2=eibrs silently selecting retpolines instead
    of AutoIBRS on SNP hosts.  Commit acaa4b5c4c85 ("x86/speculation: Do
    not enable Automatic IBRS if SEV-SNP is enabled") suppressed AutoIBRS
    by never setting X86_FEATURE_IBRS_ENHANCED, which also disabled the
    explicit spectre_v2=eibrs request.  Set the feature bit and move the
    SNP-prefers-retpoline decision into the default/auto case, where it
    belongs.

  - Patch 2 allows spectre_v2=ibrs on non-Intel vendors.  BTB Isolation
    uses legacy SPEC_CTRL.IBRS toggling to optimize the SNP VM
    exit-to-re-entry path, so AMD needs to be able to select it.  It also
    makes EFER.AUTOIBRS explicitly track the selected mitigation, which
    matters across kexec since head_64.S preserves incoming EFER bits.

Patches 3-6 are small width/ABI cleanups and the SNP_ACTIVE and
SNP-only-feature-mask groundwork, and patches 7-8 add IBPB-on-Entry and
BTB Isolation themselves.

Note that BTB Isolation is advertised unconditionally on SNP-capable
parts.  That is deliberate: the APM defines it as architecturally
present on every SEV-SNP-capable processor, so unlike IBPB-on-Entry
there is no host enumeration bit to gate on.  Patch 8 spells this out.

Changes since v4:
  https://lore.kernel.org/all/20260804235611.4053375-1-kim.phillips@amd.com/

 - Patch 1 ("x86/bugs: Allow forcing Automatic IBRS with SNP active
   using spectre_v2=eibrs"): only prefer retpoline over AutoIBRS on SNP
   hosts when CONFIG_MITIGATION_RETPOLINE is actually built in.  This
   folds v4's patch 3 into the same condition and avoids the
   select-then-fall-back ping pong.  Suggested in review:
   https://lore.kernel.org/all/lctyimdlenyb5kvfxarzajs2ggzkwn4yehxu233lojynqwa7ej@wjur3lh6szlr/

 - Patch 2 ("x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than
   Intel"): move the EFER.AUTOIBRS kexec cleanup out of
   spectre_v2_apply_mitigation() and up to the top of
   cpu_select_mitigations(), next to the existing SPEC_CTRL kexec
   cleanup, so stale state is dropped before mitigation selection rather
   than during it.  spectre_v2_apply_mitigation() now only sets the bit,
   which keeps it much closer to its original shape.  Suggested in
   review:
   https://lore.kernel.org/all/ga63o6nf7xebndlo66qqasjx7axpopyph7ilkwhvx3enfaqs4w@r4qfr6eo6kcw/

 - Subject prefix fixes, per review:
   https://lore.kernel.org/all/20260818232204.GBaoTpHK8k7wD9mMk4@fat_crate.local/
   The two x86 patches go from "cpu/bugs:" to "x86/bugs:" to match the
   tip tree convention.  Patch 3 goes from "KVM: SEV:" to "KVM: SVM:",
   since it only touches arch/x86/include/asm/svm.h.

 - Tag cleanup, per review:
   https://lore.kernel.org/all/20260818232204.GBaoTpHK8k7wD9mMk4@fat_crate.local/
   Dropped Cc: stable@kernel.org from both x86/bugs patches.  Patch 2
   drops its Fixes: too -- it enables spectre_v2=ibrs on a vendor that
   never had a use for the option rather than fixing a bug anyone is
   hitting, so neither tag was right.  Patch 1 drops the kernel test
   robot Reported-by:/Closes: pair; that report was against an earlier
   posting of this patch rather than against upstream, so there was
   nothing there for it to close.  The part of patch 1 that is genuinely
   -stable material -- an SNP host with CONFIG_MITIGATION_RETPOLINE=n
   booting with Spectre v2 unmitigated -- will be sent separately as a
   minimal backport once this lands.

 - Dropped v4's patch 3 ("cpu/bugs: Fall back to AutoIBRS when retpoline
   unavailable on SNP CPUs").  Its fallback is now subsumed by the
   CONFIG_MITIGATION_RETPOLINE test above.

 - Dropped v4's patch 1 ("x86/bugs: Only log missing retpoline when it's
   actually the missing mitigation").  After the rework above this
   series no longer needs it, but it still fixes a real spurious
   "no mitigation available!" on Intel + RETBleed with
   CONFIG_MITIGATION_IBRS_ENTRY=y, CONFIG_MITIGATION_RETPOLINE=n and
   spectre_v2=auto, where spectre_v2_update_mitigation() afterwards
   promotes SPECTRE_V2_NONE to SPECTRE_V2_IBRS.  Being posted separately
   as a standalone fix:
   https://lore.kernel.org/lkml/20260826222228.3668418-1-kim.phillips@amd.com/

 - Added Tom's Reviewed-by to patch 8

Kim Phillips (8):
  x86/bugs: Allow forcing Automatic IBRS with SNP active using
    spectre_v2=eibrs
  x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel
  KVM: SVM: Define SVM_SEV_FEAT_* flags using BIT_ULL()
  KVM: selftests: sev_init2: Use BIT_ULL for VMSA feature bit definition
  KVM: SEV: Disallow setting SNP-only features for non-SNP guests via a
    single mask
  KVM: SEV: Advertise SVM_SEV_FEAT_SNP_ACTIVE
  KVM: SEV: Add support for IBPB-on-Entry
  KVM: SEV: Add support for SNP BTB Isolation

 arch/x86/Kconfig                              |  7 ++-
 arch/x86/include/asm/cpufeatures.h            |  1 +
 arch/x86/include/asm/svm.h                    | 17 ++++--
 arch/x86/kernel/cpu/bugs.c                    | 59 ++++++++++++++-----
 arch/x86/kernel/cpu/common.c                  |  6 +-
 arch/x86/kvm/svm/sev.c                        | 21 ++++++-
 tools/arch/x86/include/asm/cpufeatures.h      |  1 +
 .../selftests/kvm/x86/sev_init2_tests.c       | 20 +++++--
 8 files changed, 96 insertions(+), 36 deletions(-)


base-commit: ec8477a492cb24f2c334847c8734ca56c7ffdd29
-- 
2.43.0

[PATCH v5 1/8] x86/bugs: Allow forcing Automatic IBRS with SNP active using spectre_v2=eibrs

[Kim Phillips]

spectre_v2=eibrs currently enables retpolines when SNP is enabled,
instead of AutoIBRS (EIBRS) because the commit that disabled
AutoIBRS if SNP is enabled stopped short of enabling
X86_FEATURE_IBRS_ENHANCED.

Change the logic to enable X86_FEATURE_IBRS_ENHANCED, and move the
decision to switch to retpolines in the default/"auto" case in
spectre_v2_select_mitigation().  This allows the existing
spectre_v2=eibrs logic to work as intended.

Condition that switch on CONFIG_MITIGATION_RETPOLINE being built in.
Otherwise spectre_v2_select_retpoline() returns SPECTRE_V2_NONE and an
SNP host with AutoIBRS available would be left completely unmitigated
against Spectre v2 in the default/auto case, which is worse than the
userspace indirect branch performance loss AutoIBRS costs.

Also emit a performance loss warning for using AutoIBRS with SNP
enabled.  AutoIBRS is activated for all three eIBRS modes via
spectre_v2_in_eibrs_mode(), so use that helper to cover
spectre_v2=eibrs, spectre_v2=eibrs,lfence, and
spectre_v2=eibrs,retpoline uniformly.  Word the warning in terms of the
eIBRS mitigation enabling AutoIBRS, rather than naming AutoIBRS as the
selected mitigation, so it reads correctly for the ,lfence and
,retpoline variants where another component is also active.

Fixes: acaa4b5c4c85 ("x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Sean Christopherson <seanjc@google.com>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/kernel/cpu/bugs.c   | 15 ++++++++++++++-
 arch/x86/kernel/cpu/common.c |  6 +-----
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 56eac5611c31..48eb1872af18 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1672,6 +1672,7 @@ static inline bool retpoline_seq_enabled(void) { return false; }
 #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n"
 #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n"
 #define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n"
+#define SPECTRE_V2_EIBRS_SNP_PERF_MSG "WARNING: eIBRS mitigation enables AutoIBRS on SEV-SNP enabled CPU, this may cause performance loss\n"
 #define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n"
 
 #ifdef CONFIG_BPF_SYSCALL
@@ -2194,7 +2195,15 @@ static void __init spectre_v2_select_mitigation(void)
 			break;
 		fallthrough;
 	case SPECTRE_V2_CMD_FORCE:
-		if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
+		/*
+		 * Prefer retpoline when SNP is enabled because AutoIBRS
+		 * degrades host userspace indirect branch performance.  Only
+		 * do so if retpoline is actually built in, otherwise AutoIBRS
+		 * is better than leaving the system unmitigated.
+		 */
+		if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) &&
+		    !(boot_cpu_has(X86_FEATURE_SEV_SNP) &&
+		      IS_ENABLED(CONFIG_MITIGATION_RETPOLINE))) {
 			spectre_v2_enabled = SPECTRE_V2_EIBRS;
 			break;
 		}
@@ -2286,6 +2295,10 @@ static void __init spectre_v2_apply_mitigation(void)
 		}
 	}
 
+	if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
+	    boot_cpu_has(X86_FEATURE_SEV_SNP))
+		pr_warn(SPECTRE_V2_EIBRS_SNP_PERF_MSG);
+
 	switch (spectre_v2_enabled) {
 	case SPECTRE_V2_NONE:
 		return;
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c7352827f491..c568d74282a8 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1496,13 +1496,9 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	/*
 	 * AMD's AutoIBRS is equivalent to Intel's eIBRS - use the Intel feature
 	 * flag and protect from vendor-specific bugs via the whitelist.
-	 *
-	 * Don't use AutoIBRS when SNP is enabled because it degrades host
-	 * userspace indirect branch performance.
 	 */
 	if ((x86_arch_cap_msr & ARCH_CAP_IBRS_ALL) ||
-	    (cpu_has(c, X86_FEATURE_AUTOIBRS) &&
-	     !cpu_feature_enabled(X86_FEATURE_SEV_SNP))) {
+	    cpu_has(c, X86_FEATURE_AUTOIBRS)) {
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 		if (!cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) &&
 		    !(x86_arch_cap_msr & ARCH_CAP_PBRSB_NO))
-- 
2.43.0

Re: [PATCH v5 1/8] x86/bugs: Allow forcing Automatic IBRS with SNP active using spectre_v2=eibrs

[Pawan Gupta]

On Wed, Aug 26, 2026 at 05:35:03PM -0500, Kim Phillips wrote:
> spectre_v2=eibrs currently enables retpolines when SNP is enabled,
> instead of AutoIBRS (EIBRS) because the commit that disabled
> AutoIBRS if SNP is enabled stopped short of enabling
> X86_FEATURE_IBRS_ENHANCED.
> 
> Change the logic to enable X86_FEATURE_IBRS_ENHANCED, and move the
> decision to switch to retpolines in the default/"auto" case in
> spectre_v2_select_mitigation().  This allows the existing
> spectre_v2=eibrs logic to work as intended.
> 
> Condition that switch on CONFIG_MITIGATION_RETPOLINE being built in.
> Otherwise spectre_v2_select_retpoline() returns SPECTRE_V2_NONE and an
> SNP host with AutoIBRS available would be left completely unmitigated
> against Spectre v2 in the default/auto case, which is worse than the
> userspace indirect branch performance loss AutoIBRS costs.
> 
> Also emit a performance loss warning for using AutoIBRS with SNP
> enabled.  AutoIBRS is activated for all three eIBRS modes via
> spectre_v2_in_eibrs_mode(), so use that helper to cover
> spectre_v2=eibrs, spectre_v2=eibrs,lfence, and
> spectre_v2=eibrs,retpoline uniformly.  Word the warning in terms of the
> eIBRS mitigation enabling AutoIBRS, rather than naming AutoIBRS as the
> selected mitigation, so it reads correctly for the ,lfence and
> ,retpoline variants where another component is also active.
> 
> Fixes: acaa4b5c4c85 ("x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled")
> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>

Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

[PATCH v5 2/8] x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel

[Kim Phillips]

Prepare for legacy IBRS toggling on AMD, where the BTB Isolation
SEV-SNP feature uses it to optimize the VM exit-to-re-entry path.
Commit 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to
support Kernel IBRS") restricted the option to Intel because that was the
only vendor that needed it at the time; nothing about the mechanism
is Intel-specific.

Keep the IBRS-trumps-retbleed logic in retbleed_update_mitigation()
Intel-only.  Legacy SPEC_CTRL.IBRS does not mitigate AMD's Branch
Type Confusion RETBleed variant (RET prediction uses the Return
Address Predictor, not the indirect branch predictors IBRS
restricts), so letting SPECTRE_V2_IBRS trump retbleed on AMD would
silently drop the UNRET/IBPB mitigation that does cover it.

On AMD the decoupling is total: retbleed mitigation selection never
consults spectre_v2=, so spectre_v2=ibrs neither adds nor removes
RETBleed coverage.  A kernel built without MITIGATION_UNRET_ENTRY and
MITIGATION_IBPB_ENTRY already reports RETBleed as "Vulnerable" via the
retbleed sysfs node and boot log regardless of the spectre_v2= value,
so there is no silent gap in the spectre_v2=ibrs path to warn about --
and a warning there would wrongly imply the Intel-style IBRS/RETBleed
coupling exists on AMD.

Also drop CPU_SUP_INTEL from CONFIG_MITIGATION_IBRS_ENTRY's depends
line: the IBRS_ENTER/IBRS_EXIT macros are vendor-neutral, and the
Intel-only restriction would silently redirect spectre_v2=ibrs to
AUTO on AMD-only kernels.

In spectre_v2_apply_mitigation(), route AutoIBRS-capable CPUs to
EFER.AUTOIBRS only for the eIBRS modes.  Previously any IBRS mode used
EFER.AUTOIBRS when the CPU had AutoIBRS, which was unreachable while
spectre_v2=ibrs was Intel-only, but would now hand spectre_v2=ibrs the
always-on AutoIBRS behaviour instead of the toggleable SPEC_CTRL.IBRS
the option asks for.

Finally, clear EFER.AUTOIBRS at the top of cpu_select_mitigations(),
alongside the existing SPEC_CTRL kexec cleanup.  head_64.S preserves
incoming EFER bits, so a kexec from a kernel that ran in AutoIBRS mode
carries the bit into the new kernel; without an explicit clear the CPU
stays in AutoIBRS mode while sysfs reports e.g. "Mitigation: IBRS" or a
retpoline mode, diverging from the actual hardware state.  On a normal
cold boot the bit is already clear, so the msr_clear_bit() is a no-op
there.  Clearing on the boot CPU suffices for APs, since it precedes the
init_real_mode() EFER snapshot used by the AP trampoline.

Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/Kconfig           |  7 +++---
 arch/x86/kernel/cpu/bugs.c | 44 +++++++++++++++++++++++++++-----------
 2 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 15fd9ec5ecac..b9a7ddef4cba 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2496,12 +2496,13 @@ config MITIGATION_IBPB_ENTRY
 
 config MITIGATION_IBRS_ENTRY
 	bool "Enable IBRS on kernel entry"
-	depends on CPU_SUP_INTEL && X86_64
+	depends on X86_64
 	default y
 	help
 	  Compile the kernel with support for the spectre_v2=ibrs mitigation.
-	  This mitigates both spectre_v2 and retbleed at great cost to
-	  performance.
+	  This mitigates spectre_v2 at great cost to performance.  On Intel,
+	  it also mitigates retbleed.  On AMD/Hygon, retbleed mitigation
+	  requires MITIGATION_UNRET_ENTRY or MITIGATION_IBPB_ENTRY.
 
 config MITIGATION_SRSO
 	bool "Mitigate speculative RAS overflow on AMD"
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 48eb1872af18..08780e0d37ec 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1305,7 +1305,14 @@ static void __init retbleed_update_mitigation(void)
 
 	/*
 	 * Let IBRS trump all on Intel without affecting the effects of the
-	 * retbleed= cmdline option except for call depth based stuffing
+	 * retbleed= cmdline option except for call depth based stuffing.
+	 *
+	 * On AMD/Hygon, legacy SPEC_CTRL.IBRS toggling does not mitigate the
+	 * Branch Type Confusion RETBleed variant: RET prediction comes from
+	 * the Return Address Predictor, not the restricted indirect branch
+	 * predictors that IBRS controls.  So keep this Intel-only and leave
+	 * AMD's software return-thunk mitigation (UNRET/IBPB) in place even
+	 * when spectre_v2=ibrs is selected.
 	 */
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
 		switch (spectre_v2_enabled) {
@@ -2166,11 +2173,6 @@ static void __init spectre_v2_select_mitigation(void)
 		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
 	}
 
-	if (spectre_v2_cmd == SPECTRE_V2_CMD_IBRS && boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
-		pr_err("IBRS selected but not Intel CPU. Switching to AUTO select\n");
-		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
-	}
-
 	if (spectre_v2_cmd == SPECTRE_V2_CMD_IBRS && !boot_cpu_has(X86_FEATURE_IBRS)) {
 		pr_err("IBRS selected but CPU doesn't have IBRS. Switching to AUTO select\n");
 		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
@@ -2286,13 +2288,18 @@ static void __init spectre_v2_apply_mitigation(void)
 	if (spectre_v2_enabled == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
 		pr_err(SPECTRE_V2_EIBRS_EBPF_MSG);
 
-	if (spectre_v2_in_ibrs_mode(spectre_v2_enabled)) {
-		if (boot_cpu_has(X86_FEATURE_AUTOIBRS)) {
-			msr_set_bit(MSR_EFER, _EFER_AUTOIBRS);
-		} else {
-			x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
-			update_spec_ctrl(x86_spec_ctrl_base);
-		}
+	/*
+	 * On AutoIBRS-capable CPUs, eIBRS is enabled through EFER.AUTOIBRS
+	 * rather than SPEC_CTRL.IBRS.  Legacy spectre_v2=ibrs keeps using
+	 * SPEC_CTRL.IBRS even there, as it needs to be toggled on kernel
+	 * entry/exit.
+	 */
+	if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
+	    boot_cpu_has(X86_FEATURE_AUTOIBRS)) {
+		msr_set_bit(MSR_EFER, _EFER_AUTOIBRS);
+	} else if (spectre_v2_in_ibrs_mode(spectre_v2_enabled)) {
+		x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
+		update_spec_ctrl(x86_spec_ctrl_base);
 	}
 
 	if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
@@ -3297,6 +3304,17 @@ void __init cpu_select_mitigations(void)
 		x86_spec_ctrl_base &= ~SPEC_CTRL_MITIGATIONS_MASK;
 	}
 
+	/*
+	 * Likewise for EFER.AUTOIBRS: head_64.S preserves the incoming EFER
+	 * bits, so a kexec from a kernel that ran in AutoIBRS mode carries the
+	 * bit into this one.  Clear it and let the mitigation selection below
+	 * rediscover it.  This also runs before init_real_mode() snapshots
+	 * EFER for the AP trampoline, so APs inherit whatever this kernel
+	 * settles on rather than the previous kernel's choice.
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_AUTOIBRS))
+		msr_clear_bit(MSR_EFER, _EFER_AUTOIBRS);
+
 	x86_arch_cap_msr = x86_read_arch_cap_msr();
 
 	cpu_print_attack_vectors();
-- 
2.43.0

Re: [PATCH v5 2/8] x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel

[Pawan Gupta]

On Wed, Aug 26, 2026 at 05:35:04PM -0500, Kim Phillips wrote:
> Prepare for legacy IBRS toggling on AMD, where the BTB Isolation
> SEV-SNP feature uses it to optimize the VM exit-to-re-entry path.
> Commit 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to
> support Kernel IBRS") restricted the option to Intel because that was the
> only vendor that needed it at the time; nothing about the mechanism
> is Intel-specific.
> 
> Keep the IBRS-trumps-retbleed logic in retbleed_update_mitigation()
> Intel-only.  Legacy SPEC_CTRL.IBRS does not mitigate AMD's Branch
> Type Confusion RETBleed variant (RET prediction uses the Return
> Address Predictor, not the indirect branch predictors IBRS
> restricts), so letting SPECTRE_V2_IBRS trump retbleed on AMD would
> silently drop the UNRET/IBPB mitigation that does cover it.
> 
> On AMD the decoupling is total: retbleed mitigation selection never
> consults spectre_v2=, so spectre_v2=ibrs neither adds nor removes
> RETBleed coverage.  A kernel built without MITIGATION_UNRET_ENTRY and
> MITIGATION_IBPB_ENTRY already reports RETBleed as "Vulnerable" via the
> retbleed sysfs node and boot log regardless of the spectre_v2= value,
> so there is no silent gap in the spectre_v2=ibrs path to warn about --
> and a warning there would wrongly imply the Intel-style IBRS/RETBleed
> coupling exists on AMD.
> 
> Also drop CPU_SUP_INTEL from CONFIG_MITIGATION_IBRS_ENTRY's depends
> line: the IBRS_ENTER/IBRS_EXIT macros are vendor-neutral, and the
> Intel-only restriction would silently redirect spectre_v2=ibrs to
> AUTO on AMD-only kernels.
> 
> In spectre_v2_apply_mitigation(), route AutoIBRS-capable CPUs to
> EFER.AUTOIBRS only for the eIBRS modes.  Previously any IBRS mode used
> EFER.AUTOIBRS when the CPU had AutoIBRS, which was unreachable while
> spectre_v2=ibrs was Intel-only, but would now hand spectre_v2=ibrs the
> always-on AutoIBRS behaviour instead of the toggleable SPEC_CTRL.IBRS
> the option asks for.
> 
> Finally, clear EFER.AUTOIBRS at the top of cpu_select_mitigations(),
> alongside the existing SPEC_CTRL kexec cleanup.  head_64.S preserves
> incoming EFER bits, so a kexec from a kernel that ran in AutoIBRS mode
> carries the bit into the new kernel; without an explicit clear the CPU
> stays in AutoIBRS mode while sysfs reports e.g. "Mitigation: IBRS" or a
> retpoline mode, diverging from the actual hardware state.  On a normal
> cold boot the bit is already clear, so the msr_clear_bit() is a no-op
> there.  Clearing on the boot CPU suffices for APs, since it precedes the
> init_real_mode() EFER snapshot used by the AP trampoline.
> 
> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>

Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

[PATCH v5 3/8] KVM: SVM: Define SVM_SEV_FEAT_* flags using BIT_ULL()

[Kim Phillips]

The VMSA's SEV_FEATURES field is 64 bits wide: struct sev_es_save_area's
sev_features is u64, as are the VMCB allowed_sev_features/guest_sev_features
controls and KVM's vmsa_features / sev_supported_vmsa_features tracking.
Define the SVM_SEV_FEAT_* flags with BIT_ULL() instead of BIT() to match
that width.

No functional change on x86-64, where unsigned long is already 64 bits and
every flag defined today is below bit 32.  It makes the flag type match the
architectural field, keeps composite masks such as the upcoming
SVM_SEV_FEAT_SNP_ONLY_MASK 64-bit, and avoids a latent trap should a future
flag land above bit 31.  The adjacent VMCB_ALLOWED_SEV_FEATURES_VALID
already uses BIT_ULL(63).

Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index aa63431ba92c..52c900bf7e20 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -305,11 +305,11 @@ static_assert((AVIC_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == AVIC_MAX_
 static_assert((X2AVIC_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AVIC_MAX_PHYSICAL_ID);
 static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AVIC_4K_MAX_PHYSICAL_ID);
 
-#define SVM_SEV_FEAT_SNP_ACTIVE				BIT(0)
-#define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT(3)
-#define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT(4)
-#define SVM_SEV_FEAT_DEBUG_SWAP				BIT(5)
-#define SVM_SEV_FEAT_SECURE_TSC				BIT(9)
+#define SVM_SEV_FEAT_SNP_ACTIVE				BIT_ULL(0)
+#define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT_ULL(3)
+#define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
+#define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
+#define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
-- 
2.43.0

[PATCH v5 4/8] KVM: selftests: sev_init2: Use BIT_ULL for VMSA feature bit definition

[Kim Phillips]

SVM_SEV_FEAT_DEBUG_SWAP was defined as 32u, a 32-bit unsigned literal.
The kernel's supported_vmsa_features is a u64 and uses BIT(5) for this
feature. Redefine the selftest macro with BIT_ULL(5) to match that
64-bit semantic and the BIT_ULL(n) form used by the additional feature
bits introduced later in this series, so every feature-bit definition in
the file is uniformly 64-bit wide. The value is unchanged (0x20); this
is a width/consistency cleanup only.

Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 87bff4fbb7ed..61a94c6eec27 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -13,7 +13,7 @@
 #include "svm_util.h"
 #include "kselftest.h"
 
-#define SVM_SEV_FEAT_DEBUG_SWAP 32u
+#define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v5 5/8] KVM: SEV: Disallow setting SNP-only features for non-SNP guests via a single mask

[Kim Phillips]

As SNP-only features get added, adding them to the valid_vmsa_features mask
in __sev_guest_init() often gets neglected.  Add SVM_SEV_FEAT_SNP_ONLY_MASK
to help group these common features together.

Also establish SNP_ONLY_FEATURES in the sev_init2 selftest as the
corresponding mask for features that must be rejected for non-SNP guests,
populate it with SVM_SEV_FEAT_SECURE_TSC, and exercise the rejection path
by masking those bits out of the features passed for SEV-ES guests.  Define
the selftest's SNP_ONLY_FEATURES as ULL so future bits can use BIT_ULL()
there without truncation against the u64 supported_vmsa_features.

Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/kvm/aaWog_UjW-M3412C@google.com/
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h                        |  2 ++
 arch/x86/kvm/svm/sev.c                            |  2 +-
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 12 +++++++-----
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 52c900bf7e20..a206a0ed2c58 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -311,6 +311,8 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
+#define SVM_SEV_FEAT_SNP_ONLY_MASK			(SVM_SEV_FEAT_SECURE_TSC)
+
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
 struct vmcb_seg {
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 5705723f1f41..3c9483733865 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -506,7 +506,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 		return -EINVAL;
 
 	if (!snp_active)
-		valid_vmsa_features &= ~SVM_SEV_FEAT_SECURE_TSC;
+		valid_vmsa_features &= ~SVM_SEV_FEAT_SNP_ONLY_MASK;
 
 	if (data->vmsa_features & ~valid_vmsa_features)
 		return -EINVAL;
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 61a94c6eec27..8269f146b1f5 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -14,16 +14,18 @@
 #include "kselftest.h"
 
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
+#define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
+
+/* Features valid only for SNP guests, rejected for SEV-ES and below. */
+#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SECURE_TSC)
 
 /*
  * Some features may have hidden dependencies, or may only work
  * for certain VM types.  Err on the side of safety and don't
  * expect that all supported features can be passed one by one
  * to KVM_SEV_INIT2.
- *
- * (Well, right now there's only one...)
  */
-#define KNOWN_FEATURES SVM_SEV_FEAT_DEBUG_SWAP
+#define KNOWN_FEATURES		(SVM_SEV_FEAT_DEBUG_SWAP | SNP_ONLY_FEATURES)
 
 int kvm_fd;
 u64 supported_vmsa_features;
@@ -108,7 +110,7 @@ void test_features(u32 vm_type, u64 supported_features)
 		if (!(supported_features & BIT_ULL(i)))
 			test_init2_invalid(vm_type,
 				&(struct kvm_sev_init){ .vmsa_features = BIT_ULL(i) },
-				"unknown feature");
+				"unknown or unsupported feature for VM type");
 		else if (KNOWN_FEATURES & BIT_ULL(i))
 			test_init2(vm_type,
 				&(struct kvm_sev_init){ .vmsa_features = BIT_ULL(i) });
@@ -157,7 +159,7 @@ int main(int argc, char *argv[])
 
 	test_features(KVM_X86_SEV_VM, 0);
 	if (have_sev_es)
-		test_features(KVM_X86_SEV_ES_VM, supported_vmsa_features);
+		test_features(KVM_X86_SEV_ES_VM, supported_vmsa_features & ~SNP_ONLY_FEATURES);
 	if (have_snp)
 		test_features(KVM_X86_SNP_VM, supported_vmsa_features);
 
-- 
2.43.0

[PATCH v5 6/8] KVM: SEV: Advertise SVM_SEV_FEAT_SNP_ACTIVE

[Kim Phillips]

Allow userspace to set the feature in kvm_sev_init.vmsa_features.

KVM still needs to set the flag for backwards compatibility, but
disallowing SVM_SEV_FEAT_SNP_ACTIVE for an SNP guest is "bizarre."

Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/kvm/aaWog_UjW-M3412C@google.com/
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h                        | 3 ++-
 arch/x86/kvm/svm/sev.c                            | 8 ++++++--
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 4 +++-
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index a206a0ed2c58..facabba26a91 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -311,7 +311,8 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
-#define SVM_SEV_FEAT_SNP_ONLY_MASK			(SVM_SEV_FEAT_SECURE_TSC)
+#define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_SECURE_TSC)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 3c9483733865..6cfb7496415e 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3257,8 +3257,12 @@ void __init sev_hardware_setup(void)
 	    cpu_feature_enabled(X86_FEATURE_NO_NESTED_DATA_BP))
 		sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
 
-	if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
-		sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+	if (sev_snp_enabled) {
+		sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
+
+		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
+			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+	}
 }
 
 void sev_hardware_unsetup(void)
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 8269f146b1f5..d70482e07141 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -13,11 +13,13 @@
 #include "svm_util.h"
 #include "kselftest.h"
 
+#define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
-#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SECURE_TSC)
+#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_SECURE_TSC)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v5 7/8] KVM: SEV: Add support for IBPB-on-Entry

[Kim Phillips]

AMD EPYC 5th generation and above processors support IBPB-on-Entry
for SNP guests, while 3rd and 4th generation processors can via
microcode patches.  By invoking an Indirect Branch Prediction Barrier
(IBPB) on VMRUN, old indirect branch predictions are prevented
from influencing indirect branches within the guest.

SNP guests may choose to enable IBPB-on-Entry by setting
SEV_FEATURES bit 21 (IbpbOnEntry).

Host support for IBPB on Entry is indicated by CPUID
Fn8000_001F_EAX[IbpbOnEntry], bit 31.

If supported, indicate support for IBPB on Entry in
sev_supported_vmsa_features bit 21 (IbpbOnEntry).

Also add SVM_SEV_FEAT_IBPB_ON_ENTRY to the sev_init2 selftest's
SNP_ONLY_FEATURES and KNOWN_FEATURES to validate it is accepted
for SNP guests and rejected for SEV-ES.

For more info, refer to page 615, Section 15.36.17 "Side-Channel
Protection", AMD64 Architecture Programmer's Manual Volume 2: System
Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).

Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
Cc: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/cpufeatures.h                | 1 +
 arch/x86/include/asm/svm.h                        | 4 +++-
 arch/x86/kvm/svm/sev.c                            | 3 +++
 tools/arch/x86/include/asm/cpufeatures.h          | 1 +
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 4 +++-
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index f70ee74b5f92..3aad2b53f59b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -472,6 +472,7 @@
 #define X86_FEATURE_ALLOWED_SEV_FEATURES (19*32+27) /* Allowed SEV Features */
 #define X86_FEATURE_SVSM		(19*32+28) /* "svsm" SVSM present */
 #define X86_FEATURE_HV_INUSE_WR_ALLOWED	(19*32+30) /* Allow Write to in-use hypervisor-owned pages */
+#define X86_FEATURE_SNP_IBPB_ON_ENTRY	(19*32+31) /* SEV-SNP IBPB on VM Entry */
 
 /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
 #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* No Nested Data Breakpoints */
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index facabba26a91..9d8107824d10 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -310,9 +310,11 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
+#define SVM_SEV_FEAT_IBPB_ON_ENTRY			BIT_ULL(21)
 
 #define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
-					 SVM_SEV_FEAT_SECURE_TSC)
+					 SVM_SEV_FEAT_SECURE_TSC | \
+					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 6cfb7496415e..20a761cf3491 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3262,6 +3262,9 @@ void __init sev_hardware_setup(void)
 
 		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
 			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+
+		if (cpu_feature_enabled(X86_FEATURE_SNP_IBPB_ON_ENTRY))
+			sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
 	}
 }
 
diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h
index 6547c0aee45b..634cd09366da 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -460,6 +460,7 @@
 #define X86_FEATURE_ALLOWED_SEV_FEATURES (19*32+27) /* Allowed SEV Features */
 #define X86_FEATURE_SVSM		(19*32+28) /* "svsm" SVSM present */
 #define X86_FEATURE_HV_INUSE_WR_ALLOWED	(19*32+30) /* Allow Write to in-use hypervisor-owned pages */
+#define X86_FEATURE_SNP_IBPB_ON_ENTRY	(19*32+31) /* SEV-SNP IBPB on VM Entry */
 
 /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
 #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* No Nested Data Breakpoints */
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index d70482e07141..f2f97dca3935 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -16,10 +16,12 @@
 #define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
+#define SVM_SEV_FEAT_IBPB_ON_ENTRY	BIT_ULL(21)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
 #define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
-					 SVM_SEV_FEAT_SECURE_TSC)
+					 SVM_SEV_FEAT_SECURE_TSC | \
+					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v5 8/8] KVM: SEV: Add support for SNP BTB Isolation

[Kim Phillips]

Advertise support for BTB Isolation via SEV_VMSA_FEATURES when SNP is
enabled.  BTB Isolation is an optional feature that can be enabled by the
guest to ensure its guest Branch Target Buffers (BTBs) are not affected
by any context outside that guest.

SNP-active guests may choose to enable the Branch Target Buffer
Isolation mode through SEV_FEATURES bit 7 (BTBIsolation).

Unlike the sibling features advertised here (Secure TSC, IBPB-on-Entry),
BTB Isolation is advertised unconditionally.  This is deliberate, not an
oversight: the AMD64 APM (Vol. 2, Section 15.36.17 "Side-Channel
Protection") defines BTB Isolation as architecturally present on every
SEV-SNP-capable processor.  There is therefore no host enumeration bit
for it (no CPUID leaf or MSR capability), by design -- unlike
IBPB-on-Entry, whose host support is enumerated via
CPUID Fn8000_001F[IbpbOnEntry] bit 31 precisely because it is not
universal.  A per-feature host gate is thus neither possible nor
meaningful; if SNP is supported, BTB Isolation is present.

Nor does the guest have to take the host's word for it.  SEV_FEATURES is
written into the VMSA by sev_es_sync_vmsa() and measured by
SNP_LAUNCH_UPDATE with SNP_PAGE_TYPE_VMSA, so bit 7 is covered by the
launch measurement and appears in the attestation report.  At runtime the
guest can additionally read the active state from SEV_STATUS bit 9
(MSR_AMD64_SNP_BTB_ISOLATION, dumped as "BTBIsol" by
sev_status_feat_names[] in arch/x86/coco/sev/core.c).  A guest requiring
BTB Isolation can therefore confirm it is active rather than trusting what
the host advertised.

Also add SVM_SEV_FEAT_BTB_ISOLATION to the sev_init2 selftest's
SNP_ONLY_FEATURES and KNOWN_FEATURES to validate it is accepted
for SNP guests and rejected for SEV-ES.

For more info, refer to page 615, Section 15.36.17 "Side-Channel
Protection", AMD64 Architecture Programmer's Manual Volume 2: System
Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).

Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
Cc: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/svm.h                        | 2 ++
 arch/x86/kvm/svm/sev.c                            | 8 ++++++++
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 9d8107824d10..0da2234b71c6 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -309,10 +309,12 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT_ULL(3)
 #define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
+#define SVM_SEV_FEAT_BTB_ISOLATION			BIT_ULL(7)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 #define SVM_SEV_FEAT_IBPB_ON_ENTRY			BIT_ULL(21)
 
 #define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_BTB_ISOLATION | \
 					 SVM_SEV_FEAT_SECURE_TSC | \
 					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 20a761cf3491..53cc6d043883 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3260,6 +3260,14 @@ void __init sev_hardware_setup(void)
 	if (sev_snp_enabled) {
 		sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
 
+		/*
+		 * Unlike Secure TSC and IBPB-on-Entry below, BTB Isolation has
+		 * no host enumeration bit to gate on: the APM defines it as
+		 * architecturally present on every SEV-SNP-capable processor.
+		 * If SNP is supported, BTB Isolation is available.
+		 */
+		sev_supported_vmsa_features |= SVM_SEV_FEAT_BTB_ISOLATION;
+
 		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
 			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
 
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index f2f97dca3935..3f592e245a66 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -15,11 +15,13 @@
 
 #define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
+#define SVM_SEV_FEAT_BTB_ISOLATION	BIT_ULL(7)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
 #define SVM_SEV_FEAT_IBPB_ON_ENTRY	BIT_ULL(21)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
 #define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_BTB_ISOLATION | \
 					 SVM_SEV_FEAT_SECURE_TSC | \
 					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
-- 
2.43.0