Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Julien Grall <julien.grall@xxxxxxx>]

On 13/02/17 16:59, Tamas K Lengyel wrote:
> On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > Hi Tamas,
> >
> >
> > On 13/02/17 16:20, Tamas K Lengyel wrote:
> > > On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
> > > <vlad.babchuk@xxxxxxxxx> wrote:
> > > > Hello,
> > > >
> > > > This e-mail is sort of follow-up to the two threads: [1] (my thread
> > > > about TEE interaction) and [2] (Edgar's thread regarding handling SMC
> > > > calls in platform_hvc). I want to discuss more broad topic there.
> > > >
> > > > Obviously, there are growing number of SMC users and current state of
> > > > SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
> > > > secure way, Xilinx wants to forward some calls directly to Secure
> > > > Monitor, while allowing to handle other in userspace, etc.
> > > >
> > > > My proposition is to gather all requirements to SMC (and HVC) handling
> > > > in one place (e.g. in this mail thread). After we' will have clear
> > > > picture of what we want, we will be able to develop some solution,
> > > > that will satisfy us all. At least, I hope so :)
> > > >
> > > > Also I want to remind, that there are ARM document called "SMC Calling
> > > > Convention" [3]. According to it, any aarch64 hypervisor "must
> > > > implement the Standard Secure and Hypervisor Service calls". At this
> > > > moment XEN does not conform to this.
> > > >
> > > > So, lets get started with the requirements:
> > > > 0. There are no much difference between SMC and HVC handling (at least
> > > > according to SMCCC).
> > > > 1. Hypervisor should at least provide own UUID and version while
> > > > called by SMC/HVC
> > > > 2. Hypervisor should forward some calls from dom0 directly to Secure
> > > > Monitor (Xilinx use case)
> > > > 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
> > > > architecture service calls, etc.
> > > > 4. Hypervisor should handle TEE calls in a secure way (e.g. no
> > > > untrusted handlers in Dom0 userspace).
> > > > 5. Hypervisor should support multiple TEEs (at least at compilation
> > > > time).
> > > > 6. Hypervisor should do this as fast as possible (DRM playback use case).
> > > > 7. All domains (including dom0) should be handled in the same way.
> > > > 8. Not all domains will have right to issue certain SMCs.
> > > > 9. Hypervisor will issue own SMCs in some cases.
> > >
> > > 10. Domains on which the monitor privileged call feature is enabled
> > > (which is by default disabled for all domains) should not be able to
> > > issue SMCs such that it reaches the firmware directly. Xen should not
> > > bounce such calls to the firmware on behalf of the domain. Xen should
> > > not alter the state of the domain automatically (ie. incrementing PC).
> > > These calls should be exclusively transfered to the monitor subscriber
> > > for further processing. HVC calls need not be included in the monitor
> > > forwarding as long as the HVC call can be governed by XSM.
> >
> > This should not be a strong requirement. Whilst in your use case you want to
> > forward all the SMCs to the monitor app, there are use case where Xen would
> > need to emulate SMCs on the behalf of the guest. For instance see PSCI
> > (arch/arm/vpsci.c).
> In my usecases it is a strong requirement. What happens when the
> monitor system is disabled is beyond my concerns - Xen can emulate or
> forward the call as it wishes. But when the monitor application is in
> use - in my usecase - it needs to be in exclusive control. If that
> breaks an in-guest application, that is acceptable in my usecase. As
> soon as there is another usecase that would need to support such an
> application while the monitor system is enabled, the monitor system
> can be fine-tuned for those needs to allow Xen to emulate. I've said
> it many times, I have nothing against doing that, but as I don't need
> it I won't be able to spend time implementing it.
Let me remind you that this discussion is not about what you implemented 
but what is a sensible design to fit everyone. I also never ask you to 
implement anything.
> > Another valid use case is Xen handling power management for device assigned
> > to the guest and having the monitor app acting as a "Trusted App".
> >
> > Regarding the HVC call governed by XSM. I think this is the wrong way to g.
> > As it was mentioned a couple of time HVC is a valid conduit for Secure
> > monitor call. You should not deny them on the basis that your monitor app is
> > not able to handle it properly. A better way would be to have a list of
> > Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app.
> I disagree. XSM needs to be in complete control of all hypercalls.
> Whether denying some of them will break an application or not is not
> Xen's concern. That is up to me as a user of Xen and XSM. If Xen
> overrides a XSM policy because we hard-coded HVCs that pass-through,
> that is a huge security policy violation. So even if we make a list of
> HVCs that should also fall under the monitor privileged call umbrella,
> it should still not override XSM. So since I would not be looking to
> emulate anything that gets forwarded as a result of an HVC call, XSM
> works for me just fine as the only thing I would do anyway is deny
> them. So why would that list help when I might as well just make my
> list more efficiently using XSM?
Again, why do you want to handle SMC and HVC differently given they are 
both a conduit for Secure Call?
Cheers,

--
Julien Grall

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