Re: [PATCH v7 17/26] KVM: nSVM: Add missing consistency check for EVENTINJ

Re: [PATCH v7 17/26] KVM: nSVM: Add missing consistency check for EVENTINJ

[Abdelkareem Abdelsaamad]

Hey,
I am currently working on hardening the Xen hypervisor's nested SVM
implementation to add the VMRUN consistency checks for injected events,
see the Xen patch discussion thread in [1].

While reviewing KVM's logic in nested_svm_event_inj_valid_exept(), I
can see that BR_VECTOR (5) and OF_VECTOR (4) are treated as
unconditionally valid. The referenced AMD APM Vol 2, Section 15.20
explicitly state otherwise:
"If the VMM attempts to inject an event that is impossible for the
guest mode (e.g., a #BR exception when the guest is in 64-bit mode),
the event injection will fail... VMRUN will immediately exit with
VMEXIT_INVALID."
"Injecting an exception (TYPE = 3) with vectors 3 or 4 behaves like
a trap raised by INT3 and INTO instructions, respectively"

Also, the APM volume 3 chapter 3 (INTO instruction), states that the
#OF triggering instruction, INTO, is Invalid in 64-bit mode.

I attempted testing the injection with Xen-Testing-Framework (XTF)
bare-minimum testing setup. I injected an exception (TYPE=3) with the
named vectors (BR_VECTOR (5) and OF_VECTOR (4)) on Genoa host. They
both caused VMEXIT_INVALID.

I think the check in nested_svm_event_inj_valid_exept() needs to be
gated on a condition that only allows Type 3 exception injections for
OF_VECTOR (4) and BR_VECTOR (5) when the guest is not in 64-bit mode.

Please, could you have a look and share your insights on the
implemented logic?

[1] https://lists.xenproject.org/archives/html/xen-devel/2026-07/msg00808.html

--Abdelkareem

Re: [PATCH v7 17/26] KVM: nSVM: Add missing consistency check for EVENTINJ

[Sean Christopherson]

On Mon, Aug 03, 2026, Abdelkareem Abdelsaamad wrote:
> Hey,
> I am currently working on hardening the Xen hypervisor's nested SVM
> implementation to add the VMRUN consistency checks for injected events,
> see the Xen patch discussion thread in [1].
> 
> While reviewing KVM's logic in nested_svm_event_inj_valid_exept(), I
> can see that BR_VECTOR (5) and OF_VECTOR (4) are treated as
> unconditionally valid. The referenced AMD APM Vol 2, Section 15.20
> explicitly state otherwise:
> "If the VMM attempts to inject an event that is impossible for the
> guest mode (e.g., a #BR exception when the guest is in 64-bit mode),
> the event injection will fail... VMRUN will immediately exit with
> VMEXIT_INVALID."
> "Injecting an exception (TYPE = 3) with vectors 3 or 4 behaves like
> a trap raised by INT3 and INTO instructions, respectively"
> 
> Also, the APM volume 3 chapter 3 (INTO instruction), states that the
> #OF triggering instruction, INTO, is Invalid in 64-bit mode.

LOL, _that's_ what SVM decides is worthy of a consistency check?

> I attempted testing the injection with Xen-Testing-Framework (XTF)
> bare-minimum testing setup. I injected an exception (TYPE=3) with the
> named vectors (BR_VECTOR (5) and OF_VECTOR (4)) on Genoa host. They
> both caused VMEXIT_INVALID.
> 
> I think the check in nested_svm_event_inj_valid_exept() needs to be
> gated on a condition that only allows Type 3 exception injections for
> OF_VECTOR (4) and BR_VECTOR (5) when the guest is not in 64-bit mode.

It'd probably require a dedicated check in nested_svm_check_cached_vmcb12(),
because the consistency check involves both control state and save state.  Given
that event injection validaton on SVM is inherently flawed due to hardware behavior
being microarchitecture specific, addressing this is very low down on the priority
list.  If someone wants to tackle it, by all means, but realistically I doubt this
will get fixed anytime soon.

> Please, could you have a look and share your insights on the
> implemented logic?
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2026-07/msg00808.html
> 
> --Abdelkareem

[PATCH v7 00/26] Nested SVM fixes, cleanups, and hardening

[Yosry Ahmed]

A group of semi-related fixes, cleanups, and hardening patches for nSVM.
The series is essentially a group of related mini-series stitched
together for syntactic and semantic dependencies. The first 17 patches
(except patch 3) are all optimistically CC'd to stable as they are fixes
or refactoring leading up to bug fixes. Although I am not sure how much
of that will actually apply to stable trees.

Patches 1-3 here are v2 of the last 3 patches in the LBRV fixes series
[1]. The first 3 patches of [1] are already upstream.

Patches 4-12 are fixes for failure handling in the nested VMRUN and
#VMEXIT code paths.

Patches 13-17 are fixes for missing or made-up consistency checks.

Patches 18-19 are renames and cleanups.

Patches 20-25 add hardening to reading the VMCB12, caching all used
fields in the save area to prevent theoritical TOC-TOU bugs, sanitizing
used fields in the control area, and restricting accesses to the VMCB12
through guest memory.

Finally, patch 26 is a selftest for nested VMRUN and #VMEXIT failures
due to failing to map vmcb12.

v6 -> v7:
- Dropped unification of VMRUN failure paths and refactoring patches
  leading up to it, consistency checks are now moved into the helper
  copying vmcb12 to cache instead of enter_svm_guest_mode().
- Clear reserved bits in dbgctl in KVM_SET_NESTED_STATE.
- Dropped consistency check on hCR0 as CR0.PG is already checked.
- Dropped redundant check on CR4.PAE in new CS consistency check.
- Correctly cache clean bits from vmcb12.
- Update selftest to use a single VMRUN instruction and avoid missing
  post-VMRUN L1 registers restore.

v6: https://lore.kernel.org/kvm/20260224223405.3270433-1-yosry@kernel.org/

[1]https://lore.kernel.org/kvm/20251108004524.1600006-1-yosry.ahmed@linux.dev/

Yosry Ahmed (26):
  KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12
  KVM: SVM: Switch svm_copy_lbrs() to a macro
  KVM: SVM: Add missing save/restore handling of LBR MSRs
  KVM: selftests: Add a test for LBR save/restore (ft. nested)
  KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN
  KVM: nSVM: Refactor checking LBRV enablement in vmcb12 into a helper
  KVM: nSVM: Refactor writing vmcb12 on nested #VMEXIT as a helper
  KVM: nSVM: Triple fault if mapping VMCB12 fails on nested #VMEXIT
  KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT
  KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID)
  KVM: nSVM: Clear EVENTINJ fields in vmcb12 on nested #VMEXIT
  KVM: nSVM: Clear tracking of L1->L2 NMI and soft IRQ on nested #VMEXIT
  KVM: nSVM: Drop nested_vmcb_check_{save/control}() wrappers
  KVM: nSVM: Drop the non-architectural consistency check for NP_ENABLE
  KVM: nSVM: Add missing consistency check for nCR3 validity
  KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS
  KVM: nSVM: Add missing consistency check for EVENTINJ
  KVM: SVM: Rename vmcb->nested_ctl to vmcb->misc_ctl
  KVM: SVM: Rename vmcb->virt_ext to vmcb->misc_ctl2
  KVM: nSVM: Cache all used fields from VMCB12
  KVM: nSVM: Restrict mapping vmcb12 on nested VMRUN
  KVM: nSVM: Use PAGE_MASK to drop lower bits of bitmap GPAs from vmcb12
  KVM: nSVM: Sanitize TLB_CONTROL field when copying from vmcb12
  KVM: nSVM: Sanitize INT/EVENTINJ fields when copying from vmcb12
  KVM: nSVM: Only copy SVM_MISC_ENABLE_NP from VMCB01's misc_ctl
  KVM: selftest: Add a selftest for VMRUN/#VMEXIT with unmappable vmcb12

 arch/x86/include/asm/svm.h                    |  20 +-
 arch/x86/kvm/svm/nested.c                     | 459 +++++++++++-------
 arch/x86/kvm/svm/sev.c                        |   4 +-
 arch/x86/kvm/svm/svm.c                        |  72 +--
 arch/x86/kvm/svm/svm.h                        |  50 +-
 arch/x86/kvm/x86.c                            |   3 +
 tools/testing/selftests/kvm/Makefile.kvm      |   2 +
 .../selftests/kvm/include/x86/processor.h     |   5 +
 tools/testing/selftests/kvm/include/x86/svm.h |  14 +-
 tools/testing/selftests/kvm/lib/x86/svm.c     |   2 +-
 .../kvm/x86/nested_vmsave_vmload_test.c       |  16 +-
 .../selftests/kvm/x86/svm_lbr_nested_state.c  | 145 ++++++
 .../kvm/x86/svm_nested_invalid_vmcb12_gpa.c   |  98 ++++
 13 files changed, 644 insertions(+), 246 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86/svm_lbr_nested_state.c
 create mode 100644 tools/testing/selftests/kvm/x86/svm_nested_invalid_vmcb12_gpa.c


base-commit: 183bb0ce8c77b0fd1fb25874112bc8751a461e49
-- 
2.53.0.473.g4a7958ca14-goog

[PATCH v7 17/26] KVM: nSVM: Add missing consistency check for EVENTINJ

[Yosry Ahmed]

According to the APM Volume #2, 15.20 (24593—Rev. 3.42—March 2024):

  VMRUN exits with VMEXIT_INVALID error code if either:
  • Reserved values of TYPE have been specified, or
  • TYPE = 3 (exception) has been specified with a vector that does not
    correspond to an exception (this includes vector 2, which is an NMI,
    not an exception).

Add the missing consistency checks to KVM. For the second point, inject
VMEXIT_INVALID if the vector is anything but the vectors defined by the
APM for exceptions. Reserved vectors are also considered invalid, which
matches the HW behavior. Vector 9 (i.e. #CSO) is considered invalid
because it is reserved on modern CPUs, and according to LLMs no CPUs
exist supporting SVM and producing #CSOs.

Defined exceptions could be different between virtual CPUs as new CPUs
define new vectors. In a best effort to dynamically define the valid
vectors, make all currently defined vectors as valid except those
obviously tied to a CPU feature: SHSTK -> #CP and SEV-ES -> #VC. As new
vectors are defined, they can similarly be tied to corresponding CPU
features.

Invalid vectors on specific (e.g. old) CPUs that are missed by KVM
should be rejected by HW anyway.

Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler")
CC: stable@vger.kernel.org
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
---
 arch/x86/kvm/svm/nested.c | 51 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 93b3fab9b415d..15f483fac28a0 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -339,6 +339,54 @@ static bool nested_svm_check_bitmap_pa(struct kvm_vcpu *vcpu, u64 pa, u32 size)
 	    kvm_vcpu_is_legal_gpa(vcpu, addr + size - 1);
 }
 
+static bool nested_svm_event_inj_valid_exept(struct kvm_vcpu *vcpu, u8 vector)
+{
+	/*
+	 * Vectors that do not correspond to a defined exception are invalid
+	 * (including #NMI and reserved vectors). In a best effort to define
+	 * valid exceptions based on the virtual CPU, make all exceptions always
+	 * valid except those obviously tied to a CPU feature.
+	 */
+	switch (vector) {
+	case DE_VECTOR: case DB_VECTOR: case BP_VECTOR: case OF_VECTOR:
+	case BR_VECTOR: case UD_VECTOR: case NM_VECTOR: case DF_VECTOR:
+	case TS_VECTOR: case NP_VECTOR: case SS_VECTOR: case GP_VECTOR:
+	case PF_VECTOR: case MF_VECTOR: case AC_VECTOR: case MC_VECTOR:
+	case XM_VECTOR: case HV_VECTOR: case SX_VECTOR:
+		return true;
+	case CP_VECTOR:
+		return guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK);
+	case VC_VECTOR:
+		return guest_cpu_cap_has(vcpu, X86_FEATURE_SEV_ES);
+	}
+	return false;
+}
+
+/*
+ * According to the APM, VMRUN exits with SVM_EXIT_ERR if SVM_EVTINJ_VALID is
+ * set and:
+ * - The type of event_inj is not one of the defined values.
+ * - The type is SVM_EVTINJ_TYPE_EXEPT, but the vector is not a valid exception.
+ */
+static bool nested_svm_check_event_inj(struct kvm_vcpu *vcpu, u32 event_inj)
+{
+	u32 type = event_inj & SVM_EVTINJ_TYPE_MASK;
+	u8 vector = event_inj & SVM_EVTINJ_VEC_MASK;
+
+	if (!(event_inj & SVM_EVTINJ_VALID))
+		return true;
+
+	if (type != SVM_EVTINJ_TYPE_INTR && type != SVM_EVTINJ_TYPE_NMI &&
+	    type != SVM_EVTINJ_TYPE_EXEPT && type != SVM_EVTINJ_TYPE_SOFT)
+		return false;
+
+	if (type == SVM_EVTINJ_TYPE_EXEPT &&
+	    !nested_svm_event_inj_valid_exept(vcpu, vector))
+		return false;
+
+	return true;
+}
+
 static bool nested_vmcb_check_controls(struct kvm_vcpu *vcpu,
 				       struct vmcb_ctrl_area_cached *control)
 {
@@ -365,6 +413,9 @@ static bool nested_vmcb_check_controls(struct kvm_vcpu *vcpu,
 		return false;
 	}
 
+	if (CC(!nested_svm_check_event_inj(vcpu, control->event_inj)))
+		return false;
+
 	return true;
 }
 
-- 
2.53.0.473.g4a7958ca14-goog

Re: [PATCH v7 17/26] KVM: nSVM: Add missing consistency check for EVENTINJ

[Abdelkareem Abdelsaamad]

Hey,
I am currently working on hardening the Xen hypervisor's nested SVM
implementation to add the VMRUN consistency checks for injected events,
see the Xen patch discussion thread in [1].

While reviewing KVM's logic in nested_svm_event_inj_valid_exept(), I
can see that BR_VECTOR (5) and OF_VECTOR (4) are treated as
unconditionally valid. The referenced AMD APM Vol 2, Section 15.20
explicitly state otherwise:
"If the VMM attempts to inject an event that is impossible for the
guest mode (e.g., a #BR exception when the guest is in 64-bit mode),
the event injection will fail... VMRUN will immediately exit with
VMEXIT_INVALID."
"Injecting an exception (TYPE = 3) with vectors 3 or 4 behaves like
a trap raised by INT3 and INTO instructions, respectively"

Also, the APM volume 3 chapter 3 (INTO instruction), states that the
#OF triggering instruction, INTO, is Invalid in 64-bit mode.

I attempted testing the injection with Xen-Testing-Framework (XTF)
bare-minimum testing setup. I injected an exception (TYPE=3) with the
named vectors (BR_VECTOR (5) and OF_VECTOR (4)) on Genoa host. They
both caused VMEXIT_INVALID.

I think the check in nested_svm_event_inj_valid_exept() needs to be
gated on a condition that only allows Type 3 exception injections for
OF_VECTOR (4) and BR_VECTOR (5) when the guest is not in 64-bit mode.

Please, could you have a look and share your insights on the
implemented logic?

[1] https://lists.xenproject.org/archives/html/xen-devel/2026-07/msg00808.html

--Abdelkareem