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. ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
