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.
This approach, I think, could be used w/ BKPT/BRK instructions on ARM as
well. After all, BKPT/BRK functionality is precisely that of INT3's with
the slight enhancement of having an #imm attached.
But, as I said, I anticipate that the actual implementation differences
for this vm-event on ARM, if using BKPT/BRK (compared to X86) will
emerge due to the fact that on X86 INT3 can be trapped all by itself,
whereas on ARM such granularity is not available for BKPT/BRK. Also,
working with the debug architecture might prove to be a little bit
elaborate. So I guess this is a question of balancing conceptual
correctness vs being practical for the short run with far less effort. :-)
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
