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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
> <sstabellini@xxxxxxxxxx> wrote:
> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> >> On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
> >> <sstabellini@xxxxxxxxxx> wrote:
> >> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> >> >> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall <julien.grall@xxxxxxx> 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > 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.
> >> >
> >> > Right, as I wrote in the other thread, I think we should be able to find
> >> > a way to satisfy Tamas' requirement as well as all the others. Of
> >> > course, once you enable the "forward all SMCs to monitor" mode, some of
> >> > the other requirements might not be met anymore, but that's acceptable
> >> > because they are for different use-cases.
> >> >
> >> >
> >> >> > 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.
> >> >
> >> > I agree with you on this.
> >> >
> >> >
> >> >> >> 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?
> >> >>
> >> >> AFAIU HVCs are used for hypercalls. If some HVCs will be used to go
> >> >> and issue a firmware call from Xen, it still doesn't change the fact
> >> >> that it was a hypercall in the first place. So it should be governed
> >> >> by XSM. Am I missing something?
> >> >
> >> > The problem is the following: on some platforms an operating system
> >> > might issue a firmware call via HVC instead of SMC. It's outside of our
> >> > control. The monitor won't be able to receive that event, because the
> >> > infrastructure doesn't allow to forward HVC calls to the monitor. It
> >> > might break your use-case.
> >>
> >> That's right. But HVCs should still fall under XSM control, while SMCs
> >> aren't (and shouldn't). I mean, the operating system needs to have
> >> some understanding of the hypervisor it is running on in order to use
> >> HVCs for do firmware calls through the VMM. So it's not like the OS
> >> can just use arbitrary HVC calls to get bounced to the firmware by
> >> Xen, correct?
> >
> > As strange as it sounds, I don't think we can make that assumption,
> > unfortunately.
> 
> That certainly does sound very strange to me.
> 
> >
> >> > To properly support firmware calls monitoring, we should make no
> >> > distinctions between SMC and HVC, as specified by the SMC calling
> >> > convention.
> >>
> >> Well, if in the future if we extend the monitoring system to also
> >> record these HVCs that would be something to record in the monitor
> >> event. That should be fairly straight forward though.
> >>
> >> >
> >> > To do this right, we need to be able to specify which SMCs/HVCs get
> >> > forwarded to the monitor. Forwarding all SMCs, but no HVCs, is not a
> >> > complete solution, although it should work in the vast majority of
> >> > cases.
> >> >
> >> > I would put down as a requirement that we want to be able to monitor any
> >> > HVC/SMC calls, while accepting the compromise that as an initial
> >> > implementation only SMCs can actually be monitored.
> >>
> >> I agree. While I understand that in those cases HVCs should get
> >> treated equivalent to SMCs, ie. get forwarded via the monitor
> >> interface, but if I can choose to just deny those with XSM while
> >> monitoring regular SMCs, that would be an OK solution for me for now.
> >> But if we really need to make a list, my list is fairly straight
> >> forward: all HVCs that would be used to trigger a firmware call need
> >> to be routed through the monitor system to ensure there is no back
> >> channel anywhere from an untrusted guest to the firmware bypassing
> >> Xen.
> >
> > Right, makes sense, so the requirement should be:
> >
> >   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 firmware calls via SMCs/HVCs so that such calls reach 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.
> >   Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual
> >   ARM architecture service calls remain unaffected.
> >
> > Does that work for you?
> 
> It works iff hypercalls, virtual psci calls and virtual CPU services
> can be denied with XSM. If that's not the case, then no, in that case
> all those HVC calls that would be bounced to the firmware need to be
> hooked into the monitor system as well. Ideally as soon as they are
> being introduced to the Xen codebase.

I don't think we have XSM hooks for all of those today, but I think
everybody would agree that it is be a good idea to have them.

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