Re: [PATCH v6] x86/nSVM: Check injected event consistency

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.09.2026 17:50, Abdelkareem Abdelsaamad wrote:
> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
> debugging complications, security and performance implications. The APM
> volume #2, Section 15.20, Event Injection, states the two possibilities that
> VMRUN will immediately exit with VMEXIT_INVALID due to the injected event.
> These are
> • Reserved values of TYPE have been specified.
> • 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).
> 
> Furthermore, reading through the APM shows that the exception vector validity
> can also depend on the guest mode, the CPU generation and the
> microarchitectural constraints. Some vectors are only valid starting with the
> specific CPU generation that introduced the corresponding feature, the guest
> mode or whether the guest opted-in for specific CPU capability. The Upstream
> KVM introduced a similar consistency check that reflects on this dependency
> with the commit
> 7e79f71bca5c ("KVM: nSVM: Add missing consistency check for EVENTINJ").
> However, the KVM implementation did allow the Overflow (X86_EXC_OF) and the
> BOUND Range (X86_EXC_BR) vectors injection in 64-bit mode. According to the 
> APM
> Volume #2, Section 15.20, Event Injection and Volume #3, Chapter 3,
> General-Purpose Instruction Reference (INTO Interrupt to Overflow Vector),
> injecting these exceptions while the guest is in 64-bit mode is invalid and
> triggers an immediate VMEXIT_INVALID. This architectural mismatch in the KVM
> implementation was reported here:
> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@xxxxxxxxxx/
> 
> To verify the hardware behaviour with the various vectors, A case-by-case
> testing on 64-bit mode Windows guest is performed. The hardware exception 
> event
> is manually injected at the end of svm_vmexit_handler and the consequence
> is observed:
>  - If VMEXIT_INVALID is triggered, the injection is invalid.
>  - If a guest triple fault is triggered, the event passed the hardware checks
>    and completed the event delivery. It is valid.
> 
> Extend the VMCB validation to check for the VMCB event injection 
> inconsistency.
> 
> While at it, extend the svm_vmcb_isvalid usage to the non-nested 
> VMEXIT_INVALID
> debugging.
> 
> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@xxxxxxxxxx>
> ---
> Changes in v6:
> - Replace APM revision numbers with section titles in the commit message and
>   in the comments.
> - Review and Correct the testing matrix
>   - Correct the swapped Naples/Genoa entries in the testing matrix.
>   - Add the missing X86_EXC_MC, X86_EXC_XM along with the other missing
>     vectors.
> - Combine #BR and #OF exception vectors handling.
> - Change the vmcb_valid_event_inj_types_mask type to unsigned int.
> - Drop the logging of the exception type from the invalid vector error log.
> - Drop the clean up of the svm_vmcb_isvalid function.

Code changes themselves look good now, yet of course only as far as we
have reached agreement. The remaining open issues (#XM, #MC) are
attempted to be covered by the testing matrix, yet I remain unconvinced.
I'd therefore make ack-ing this change dependent on buy-in by other
x86 maintainers.

> ---
> Testing:
>  - Using a locally developed XTF nested virt setup, I manually tested VMRUN
>    instruction handling with a malformed VMCB:
>    1) Inject event with the type (7).
>       The hypervisor logs show the message
>       (XEN) [  645.155609] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
>             Injected Event Type: 0x7.
>    2) Inject event with the exception value (3) and the vector value (2) for
>       NMI. The hypervisor logs show the message
>       (XEN) [  645.157277] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
>             exception vector: 0x2.
>    3) To perform more detailed bare-metal testing, I set up a testing matrix
>       using a XenServer Windows 10 64-bit VM and manually injected the
>       various events according to the testing matrix below:
>  ----------------------------------------------------------------------------
> | Ex. Vector |    AMD Naples    |     AMD Genoa    |    Testing Conditions   |
> |------------|------------------|------------------|-------------------------|
> | X86_EXC_OF | VMEXIT_INVALID   |  VMEXIT_INVALID  | - Verified that 64bit   |
> | X86_EXC_BR |                  |                  | mode is active before   |
> |            |                  |                  | injecting the event.    |
> |------------|------------------|------------------|-------------------------|
> |            |                  |                  | - Verified that the     |
> |            |                  |                  | Genoa host does not have|
> | X86_EXC_CP | VMEXIT_INVALID   |Guest Triple fault| guest_cr[4] X86_CR4_CET |
> |            |                  |                  | set and the VMCB does   |
> |            |                  |                  | not have CR4 X86_CR4_CET|
> |            |                  |                  | set                     |
> |------------|------------------|------------------|-------------------------|
> |            |                  |                  | - APM states only valid |
> | X86_EXC_HV | VMEXIT_INVALID   |  VMEXIT_INVALID  | to inject into VMSAs    |
> |            |                  |                  | that execute with       |
> |            |                  |                  | Restricted Injection.   |
> |------------|------------------|------------------|-------------------------|
> | X86_EXC_DE |                  |                  | - Verified that hosts   |
> | X86_EXC_DB |                  |                  | do not have guest_cr[4] |
> | X86_EXC_UD |                  |                  | X86_CR4_OSXMMEXCPT set  |
> | X86_EXC_NM |                  |                  | and the VMCB does not   |
> | X86_EXC_DF |                  |                  | have CR4                |
> | X86_EXC_TS |                  |                  | X86_CR4_OSXMMEXCPT set  |
> | X86_EXC_NP |Guest Triple fault|Guest Triple fault| with the vector         |
> | X86_EXC_SS |                  |                  | X86_EXC_XM.             |
> | X86_EXC_GP |                  |                  | with the vector         |
> | X86_EXC_PF |                  |                  | X86_EXC_MC.             |

This continues to be odd: I can't help the impression that the start of the
last sentence was lost. With #XM and #MC being somewhat special anyway, I
wonder whether they wouldn't have deserved their own separate cells.

Jan