On Apr 13, 2016 6:06 AM, "Andrew Cooper" <andrew.coop...@citrix.com> wrote: > > On 13/04/16 11:53, Corneliu ZUZU wrote: >> >> 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? > > > That is certainly the idea. > > >> I'm curious if behind the scenes Xen also write-protects that page such that the guest does not overwrite the INT3. > > > Haha. I refer to my "Whether this works or not is a separate matter" statement. > > No-one has made a product feature out of external debugging of a guest, which means there are almost certainly logic holes and bugs. This write-protection looks like a prime issue which hasn't been considered. >
In the DRAKVUF system that's exactly what I do, I mark the page execute only so that the guest is unable to locate/overwrite injected breakpoints without notice. If it were to overwrite injected breakpoints with its own, then we would be able to tell that the trap is both for external and internal use. So there isn't much of an issue there. The main issue is with the racecondition in multi-vCPU guests when the purely external-use breakpoint has to be removed to allow the guest to continue. It can be solved nicely though with altp2m. I did a write-up for the Xen blog about it a couple months ago and sent it to publicity but has not appeared yet. Lars? Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
