Re: [PATCH] vm_event: Implement ARM SMC events

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Corneliu ZUZU <czuzu@bitdefender.com>,
	Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Keir Fraser <keir@xen.org>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] vm_event: Implement ARM SMC events
Date: Wed, 13 Apr 2016 13:02:16 +0100	[thread overview]
Message-ID: <570E3548.3040502@citrix.com> (raw)
In-Reply-To: <570E2513.5060502@bitdefender.com>

[-- Attachment #1.1: Type: text/plain, Size: 3159 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5984 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel