Re: [PATCH] x86/hvm: Unilaterally inject #UD for unknown VMExits

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

On Mon Dec 1, 2025 at 3:52 PM CET, Alejandro Vallejo wrote:
> On Fri Nov 28, 2025 at 6:47 PM CET, Andrew Cooper wrote:
>> While we do this for unknown user mode exits, crashing for supervisor mode
>> exits is unhelpful.  Intel in particular expect the unknown case to be #UD
>> because they do introduce new instructions with new VMEXIT_* codes without
>> other enablement controls.  e.g. MSRLIST, USER_MSR, MSR_IMM, but AMD have
>> RDPRU and SKINIT as examples too.
>
> I don't know how often Intel adds intercepts (or whatever the VMX equivalent is)
> without default-off knobs, but there's a potentially dangerous assumption here
> about all intercepts being synchronous with the executed instruction. Some might
> depend on other events (i.e: NMIs, IRQs, IPIs, etc) and injecting #UD in those
> cases would be very insecure for the guest. It might encourage the kernel to
> interpret the current instruction that the kernel can't know wasn't meant to
> ever trigger #UD. This would be an integrity-compromising mistake to make.
>
> IOW, I think this is a dangerous default to have and Xen should just crash the
> domain irrespective of CPL. At least on SVM. If a guest executes SKINIT and it
> doesn't exist 

... and it doesn't exist, it's fine for a guest to crash. The domain crashing is
a Xen bug, but the bug triggering is a guest bug. And that's ok.

Sorry, those linnes got lost.

Cheers,
Alejandro