On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall <julien.gr...@arm.com> wrote: > > > On 13/02/17 16:59, Tamas K Lengyel wrote: >> >> On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall <julien.gr...@arm.com> >> 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.babc...@gmail.com> 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?
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? Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
