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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

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.
>
>
> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel