[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events
- To: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>, Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Wed, 13 Apr 2016 11:17:57 +0100
- Cc: Wei Liu <wei.liu2@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 13 Apr 2016 10:18:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 13/04/16 09:55, Corneliu ZUZU wrote:
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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|