On 4/13/2016 1:17 PM, Andrew Cooper wrote:

On 13/04/16 09:55, Corneliu ZUZU wrote:

I would have to double check but AFAIK those instructions can't be
configured to trap to the hypervisor directly. So while SMC was not
intended to be a breakpoint, conceptually it's the closest thing we have
an on ARM to the INT3 instruction when configured to trap to the VMM.

Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since activating this bit would imply additional (in this context -unwanted-) traps, the performance hit of having this bit set might be significant.

Right, actually I believe KVM already implemented this, I was just under the impression it was only for aarch64. As for performance overhead I'm not that worried about it, rather I need to make sure the presence of the monitoring can remain stealthy. I know on KVM for example this type of trapping renders the guest to be unable to use singlestepping, which would easily reveal the presence of the external monitor (see https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014589.html). So this will need to be looked at carefully.

That seems to apply to single-stepping only, which would be a different matter. As for stealthiness or not limiting the guest, IMO that shouldn't be a problem with BKPT/BRK, since I believe you can inject the breakpoint exception into the guest as if no hypervisor trap occured in between (of course, once you decide whether that breakpoint is Xen's or guest-internal). But what about X86? How is stealthiness achieved there? Is INT3 entirely not available for the guest anymore when guest-debugging is enabled or are ALL INT3's reported by Xen as software breakpoint vm-events?

In x86, attaching a debugger to the domain causes #DB and #BP exceptions to be intercepted by Xen, rather than handled directly by the domain (actually, since XSA-156, #DB is intercepted under all circumstances, to avoid security issues).  The debugger receives all debug events, and should filer the ones it has introduced vs the ones present from in-guest activities.

~Andrew

(Whether this works or not is a separate matter, and largely depends on the debugger.)

And after this filtering, I guess if the debug event proves to be introduced by in-guest activities, the exception is reintroduced to preserve transparency, correct?

I'm curious if behind the scenes Xen also write-protects that page such that the guest does not overwrite the INT3.