|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
On Tue, Feb 14, 2017 at 11:06 AM, Julien Grall <julien.grall@xxxxxxx> wrote: > Hi, > > > On 02/13/2017 10:14 PM, Stefano Stabellini wrote: >> >> 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. > > > It is not strange, a guest knowing that it will run on a hypervisor could > potentially only use HVC. Furthermore there are some platform with no EL3 > support, so SMC instruction will become undefined. A guest might want to use > HVC and expect the hypervisor to emulate it. > >>> >>>> >>>>>> 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. > > > I disagree here. If you add XSM hook in vPSCI, it means you will allow the > user to deny CPU bring up. In this case, what is the point to have a guest > with multiple CPUs? > > Regarding forwarding to the monitor app, this is very similar to MMIO region > emulated by either Xen or QEMU (in x86 case) they cannot be forwarded. Are > you going to add XSM in the MMIO emulation too? Are you going to emulate the > vITS/vGIC/vUART/pl011 in the monitor app? > I have no plans to emulate anything. If it breaks an application, it breaks an application. My setup is not targeted towards arbitrary OS/app combinations. It is targeting a very specific setup. As long as the option is available to deny arbitrary applications talking directly to the firmware, I'm OK with it, be that with XSM or by forwarding via the monitor interface where I can deny such calls. At this point I don't think I can add any more information to drive this conversation forward.. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |