HW breakpoint on physical address w/ VM

[Elazar Leibovich]

I recently read about upcoming features from Intel[0]. One of those
features are of EPT subpage permission, which is essentially another "EPT"
table, with 128-bytes granularity, allowing you to set extra permissions
for a certain part of a page.

Then, I remembered my old question, and realized I now have some sort-of
answer.

This feature allows one to get more-or-less hardware breakpoint for a KVM
guest, giving you effectively infinite number of breakpoints to any guest
physical address (with a slightly larger granularity than "real" debug
registers).

In fact KVM API is gaining the additional ioctls these days[1], and if I
were maintaining the QEMU, I'd add to gdb-stub.c the ability to break on a
HW address by using special, non-cannonical virtual prefix. Say hbr
*0x80007....<phys-addr> would break when executing <phys-addr>, by
recognizing the special prefix.

[0]
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
[1] https://patchwork.kernel.org/patch/10007161/

On Sun, Aug 30, 2015 at 7:58 AM, Muli Ben-Yehuda <mulix at mulix.org> wrote:

> On Sat, Aug 29, 2015 at 10:44:17PM +0300, Elazar Leibovich wrote:
>
> > Oh, and the idea of the KVM patch is, for each physical HW bp, add a
> > relevant entry in the spt, and set the hardware breakpoint
> > there. This is assuming KVM HW bp works like I think they do.
>
> I'm not sure I follow what you are trying to do. But assuming you are
> working on a guest OS where some code running in guest context is
> modifying the page tables, assuming you always see the same PTE or the
> same range of PTEs being modified, I would just set the PTE mapping
> that PTE page to RO in KVM and wait for the inevitable exit. The stack
> trace should then point to the culprit. This crude but simple
> technique has served me well while writing nom (my operating
> system). Several time when it hadn't, it turned out that my network
> adapter was DMA'ing directly into memory it wasn't supposed to.
>
> Cheers,
> Muli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20171023/9c1425a7/attachment.html>