Re: Causing VMEXITs when kprobes are hit in the guest VM

[Sean Christopherson <seanjc@google.com>]

On Sun, May 01, 2022, Arnabjyoti Kalita wrote:
> Hello all,
> 
> I intend to run a kernel module inside my guest VM. The kernel module
> sets kprobes on a couple of functions in the linux kernel. After
> registering the kprobes successfully, I can see that the kprobes are
> being hit repeatedly.
> 
> I would like to cause a VMEXIT when these kprobes are hit. I know that
> kprobes use a breakpoint instruction (INT 3) to successfully execute
> the pre and post handlers. This would mean that the execution of the
> instruction INT 3 should technically cause a VMEXIT.

No, it should cause #BP.  KVM doesn't intercept #BP by default because there's no
reason to do so.

> However, I do not get any software exception type VMEXITs when these kprobes
> are hit.
> 
> I have used the commands "perf kvm stat record" and "perf kvm stat
> report --event=vmexit" to try and observe the VMEXIT reasons and I do
> not see any VMEXIT of type "EXCEPTION_NMI" being returned in the
> period that the kprobe was being hit.
> 
> My host uses a modified Linux kernel 5.8.0 while my guest runs a 4.4.0
> Linux kernel. Both the guest and the host use the x86_64 architecture.
> I am using QEMU version 5.0.1. What changes are needed in the Linux
> kernel to make sure that I get an exception in the form of a VMEXIT
> whenever the kprobes are hit?

This can be done entirely from userspace by enabling KVM_GUESTDBG_USE_SW_BP, e.g.

	struct kvm_guest_debug debug;

	memset(&debug, 0, sizeof(debug));
	debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
	ioctl(vcpu->fd, KVM_SET_GUEST_DEBUG, &debug);

That will intercept #BP and exit to userspace with KVM_EXIT_DEBUG.  Note, it's
userspace's responsibility to re-inject the #BP if userspace wants to forward the
#BP to the guest.

There's a bit more info in Documentation/virt/kvm/api.rst under KVM_SET_GUEST_DEBUG.