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

Reply via email to