From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH] vm_event: Implement ARM SMC events Date: Tue, 12 Apr 2016 09:01:35 -0600 Message-ID: References: <1460404042-31179-1-git-send-email-tamas@tklengyel.com> <570CA910.8050404@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3993161280612750721==" Return-path: Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apzoy-00078L-PZ for xen-devel@lists.xenproject.org; Tue, 12 Apr 2016 15:01:40 +0000 Received: by mail-yw0-f177.google.com with SMTP id t10so27612543ywa.0 for ; Tue, 12 Apr 2016 08:01:36 -0700 (PDT) In-Reply-To: <570CA910.8050404@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Corneliu ZUZU Cc: Wei Liu , Keir Fraser , Razvan Cojocaru , Stefano Stabellini , Andrew Cooper , Ian Jackson , Julien Grall , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org --===============3993161280612750721== Content-Type: multipart/alternative; boundary=94eb2c077550ff26ef05304aef45 --94eb2c077550ff26ef05304aef45 Content-Type: text/plain; charset=UTF-8 On Apr 12, 2016 01:51, "Corneliu ZUZU" wrote: > > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: >> >> From: Tamas K Lengyel >> >> The ARM SMC instructions are already configured to trap to Xen by default. In >> this patch we allow a user-space process in a privileged domain to receive >> notification of when such event happens through the vm_event subsystem. >> >> This patch will likely needs to be broken up into several smaller patches. >> Right now what this patch adds (and could be broken into smaller patches >> accordingly): >> - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs on ARM >> - Implement vm_event register fill/set routines for ARM. This required >> removing the function from common as the function prototype now >> differs on the two archs. >> - Sending notification as SOFTWARE_BREAKPOINT vm_event from the SMC trap >> handlers. >> - Extend the xen-access test tool to receive SMC notification and step >> the PC manually in the reply. >> >> I'm sending it as an RFC to gather feedback on what has been overlooked in this >> revision. This patch has been tested on a Cubietruck board and works fine, >> but would probably not work on 64-bit boards. > > > Hi Tamas, > > If I may, I'm still unable to work at the moment, being ill, but I'm checking the xen-devel lists from time to time. > Your patch caught my attention, reminding me of the conversation we had some time ago on this matter. > The only real reason I don't see SMC (secure-monitor-call) as being an ideal candidate for this is that, according to the ARM manuals, SMC should directly cause undefined exception if executed from user-mode (EL0), instead of a hypervisor trap - isn't that the case on the machine you tested this on or is this really only for the EL1 of domains? That's correct, it can only be issued by the kernel. So as long as you want to monitor the kernel it can be used just fine. I can also envision trampoline-like traps (syscalls injected into EL0 to trigger SMC) but that's beyond the scope I intend this for now. > > Also: > - SMC, by definition, is a call to the secure side, it doesn't relate to debugging directly (it's a syscall to the 'secure' side). There is a viable INT3 equivalent on ARM, that being the BKPT/BRK instruction, using that instead would require a bit more effort (but would, conceptually, be more correct) and might be less performant, I suppose that's why you didn't go for that? 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. > - SMC can be disabled by the secure side (over which Xen doesn't have control) - not really a problem on though, since the hypervisor trap happens before that check > But these 2 are conceptual problems, they don't impede usage of SMC as you intend in practice. Sure, the TrustZone is more privileged then the hypervisor so you need to take that into account as well when you consider your threat model. If the TZ is malicious though IMHO there isn't much you can do on the hypervisor side anyway. So in the usecase I have for this I control the TZ as well. Tamas --94eb2c077550ff26ef05304aef45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 12, 2016 01:51, "Corneliu ZUZU" <czuzu@bitdefender.com> wrote:
>
> On 4/11/2016 10:47 PM, Tamas K Lengyel wrote:
>>
>> From: Tamas K Lengyel <tklengyel@sec.in.tum.de>
>>
>> The ARM SMC instructions are already configured to trap to Xen by = default. In
>> this patch we allow a user-space process in a privileged domain to= receive
>> notification of when such event happens through the vm_event subsy= stem.
>>
>> This patch will likely needs to be broken up into several smaller = patches.
>> Right now what this patch adds (and could be broken into smaller p= atches
>> accordingly):
>> =C2=A0 =C2=A0 =C2=A0- Implement monitor_op domctl handler for SOFT= WARE_BREAKPOINTs on ARM
>> =C2=A0 =C2=A0 =C2=A0- Implement vm_event register fill/set routine= s for ARM. This required
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0removing the function from commo= n as the function prototype now
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0differs on the two archs.
>> =C2=A0 =C2=A0 =C2=A0- Sending notification as SOFTWARE_BREAKPOINT = vm_event from the SMC trap
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handlers.
>> =C2=A0 =C2=A0 =C2=A0- Extend the xen-access test tool to receive S= MC notification and step
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the PC manually in the reply. >>
>> I'm sending it as an RFC to gather feedback on what has been o= verlooked in this
>> revision. This patch has been tested on a Cubietruck board and wor= ks fine,
>> but would probably not work on 64-bit boards.
>
>
> Hi Tamas,
>
> If I may, I'm still unable to work at the moment, being ill, but I= 'm checking the xen-devel lists from time to time.
> Your patch caught my attention, reminding me of the conversation we ha= d some time ago on this matter.
> The only real reason I don't see SMC (secure-monitor-call) as bein= g an ideal candidate for this is that, according to the ARM manuals, SMC sh= ould directly cause undefined exception if executed from user-mode (EL0), i= nstead of a hypervisor trap - isn't that the case on the machine you te= sted this on or is this really only for the EL1 of domains?

That's correct, it can only be issued by the kernel. So = as long as you want to monitor the kernel it can be used just fine. I can a= lso envision trampoline-like traps (syscalls injected into EL0 to trigger S= MC) but that's beyond the scope I intend this for now.

>
> Also:
> - SMC, by definition, is a call to the secure side, it doesn't rel= ate to debugging directly (it's a syscall to the 'secure' side)= . There is a viable INT3 equivalent on ARM, that being the BKPT/BRK instruc= tion, using that instead would require a bit more effort (but would, concep= tually, be more correct) and might be less performant, I suppose that's= why you didn't go for that?

I would have to double check but AFAIK those instructions ca= n'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.=

> - SMC can be disabled by the secure side (over which Xe= n doesn't have control) - not really a problem on though, since the hyp= ervisor trap happens before that check
> But these 2 are conceptual problems, they don't impede usage of SM= C as you intend in practice.

Sure, the TrustZone is more privileged then the hypervisor s= o you need to take that into account as well when you consider your threat = model. If the TZ is malicious though IMHO there isn't much you can do o= n the hypervisor side anyway. So in the usecase I have for this I control t= he TZ as well.

Tamas

--94eb2c077550ff26ef05304aef45-- --===============3993161280612750721== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============3993161280612750721==--