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

From: Sean Christopherson <seanjc@google.com>
To: Arnabjyoti Kalita <akalita@cs.stonybrook.edu>
Cc: Jim Mattson <jmattson@google.com>, kvm@vger.kernel.org
Subject: Re: Causing VMEXITs when kprobes are hit in the guest VM
Date: Wed, 11 May 2022 15:04:23 +0000	[thread overview]
Message-ID: <YnvQd5zvDlop7oRK@google.com> (raw)
In-Reply-To: <CAJGDS+G+z9S6QDEGRatR5u+q-5X_MAiWqnTsjf4L=4+PrThdsQ@mail.gmail.com>

On Wed, May 11, 2022, Arnabjyoti Kalita wrote:
> What could be the various ways a guest could handle #BP?

The kernel uses INT3 to patch instructions/flows, e.g. for alternatives.  For those,
the INT3 handler will unwind to the original RIP and retry.  The #BP will keep
occurring until the patching completes.  See text_poke_bp_batch(), poke_int3_handler(),
etc...

Userspace debuggers will do something similar; after catching the #BP, the original
instruction is restored and restarted.

The reason INT3 is a single byte is so that software can "atomically" trap/patch an
instruction without having to worry about cache line splits.  CPUs are guaranteed
to either see the INT3 or the original instruction in its entirety, i.e. other CPUs
will never decode a half-baked instruction.

The kernel has even fancier uses for things like static_call(), e.g. emulating
CALL, RET, and JMP from the #BP handler.

> Can we "make" the guest skip the instruction that caused the #BP ?

Well, technically yes, that's effectively what would happen if the host skips the
INT3 and doesn't inject the #BP.  Can you do that and expect the guest not to
crash?  Nope.