On Wed, Aug 17, 2022 at 10:08:45AM +0800, Chenyi Qiang wrote: > There are cases that malicious virtual machine can cause CPU stuck (due > to event windows don't open up), e.g., infinite loop in microcode when > nested #AC (CVE-2015-5307). No event window means no event (NMI, SMI and > IRQ) can be delivered. It leads the CPU to be unavailable to host or > other VMs. Notify VM exit is introduced to mitigate such kind of > attacks, which will generate a VM exit if no event window occurs in VM > non-root mode for a specified amount of time (notify window). > > A new KVM capability KVM_CAP_X86_NOTIFY_VMEXIT is exposed to user space > so that the user can query the capability and set the expected notify > window when creating VMs. The format of the argument when enabling this > capability is as follows: > Bit 63:32 - notify window specified in qemu command > Bit 31:0 - some flags (e.g. KVM_X86_NOTIFY_VMEXIT_ENABLED is set to > enable the feature.) > > Because there are some concerns, e.g. a notify VM exit may happen with > VM_CONTEXT_INVALID set in exit qualification (no cases are anticipated > that would set this bit), which means VM context is corrupted. To avoid > the false positive and a well-behaved guest gets killed, make this > feature disabled by default. Users can enable the feature by a new > machine property: > qemu -machine notify_vmexit=on,notify_window=0 ... The patch looks sane to me; I only read the KVM interface, though. Worth add a section to qemu-options.hx? It'll also be worthwhile to mention the valid range of notify_window and meaning of zero (IIUC that's also a valid input, just use the hardware default window size). Thanks, > > A new KVM exit reason KVM_EXIT_NOTIFY is defined for notify VM exit. If > it happens with VM_INVALID_CONTEXT, hypervisor exits to user space to > inform the fatal case. Then user space can inject a SHUTDOWN event to > the target vcpu. This is implemented by injecting a sythesized triple > fault event. -- Peter Xu
