All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnabjyoti Kalita <akalita@cs.stonybrook.edu>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: Causing VMEXITs when kprobes are hit in the guest VM
Date: Fri, 6 May 2022 10:44:25 +0530	[thread overview]
Message-ID: <CAJGDS+F0hB=0bj8spt9sophJyhdXTkYXK8LXUrt=7mov4s2JJA@mail.gmail.com> (raw)
In-Reply-To: <YnGUazEgCJWgB6Yw@google.com>

Dear Sean,

Thank you very much for your answer.

I managed to set a Hardware Breakpoint using the API you provided, in
userspace, and managed to get a VMEXIT of type "KVM_EXIT_DEBUG". I
will not re-inject the #BP since I do not necessarily want the guest
to do anything with it. All I will do is just record the CPU ID of the
cpu (in userspace) that caused this breakpoint and let the guest
continue execution.

Best Regards,
Arnabjyoti Kalita

On Wed, May 4, 2022 at 2:15 AM Sean Christopherson <seanjc@google.com> wrote:
>
> 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.

  reply	other threads:[~2022-05-06  5:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01 15:30 Causing VMEXITs when kprobes are hit in the guest VM Arnabjyoti Kalita
2022-05-03 20:45 ` Sean Christopherson
2022-05-06  5:14   ` Arnabjyoti Kalita [this message]
2022-05-07  6:30     ` Arnabjyoti Kalita
2022-05-11  0:49       ` Jim Mattson
2022-05-11 13:59         ` Sean Christopherson
2022-05-11 14:08           ` Arnabjyoti Kalita
2022-05-11 14:16             ` Sean Christopherson
2022-05-11 14:38               ` Arnabjyoti Kalita
2022-05-11 15:04                 ` Sean Christopherson
2022-05-11 17:02                   ` Arnabjyoti Kalita
2022-05-23 19:44                     ` Arnabjyoti Kalita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJGDS+F0hB=0bj8spt9sophJyhdXTkYXK8LXUrt=7mov4s2JJA@mail.gmail.com' \
    --to=akalita@cs.stonybrook.edu \
    --cc=kvm@vger.kernel.org \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.