Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hi Julien,



On 29 November 2016 at 20:55, Julien Grall <julien.grall@xxxxxxx> wrote:
> Hi Volodymyr,
>
> On 29/11/16 17:40, Volodymyr Babchuk wrote:
>>
>> On 29 November 2016 at 18:02, Julien Grall <julien.grall@xxxxxxx> wrote:
>>>
>>> On 29/11/16 15:27, Volodymyr Babchuk wrote:
>>>>
>>>> On 28 November 2016 at 22:10, Julien Grall <julien.grall@xxxxxxx> wrote:
>>>>>
>>>>> On 28/11/16 18:09, Volodymyr Babchuk wrote:
>>>>>>
>>>>>> On 28 November 2016 at 18:14, Julien Grall <julien.grall@xxxxxxx>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 24/11/16 21:10, Volodymyr Babchuk wrote:
>>>
>>> I don't follow your point here. Why would the SMC handler need to map the
>>> guest memory?
>>
>> Because this is how parameters are passed. We can pass some parameters
>> in registers, but for example in OP-TEE registers hold only address of
>> command buffer. In this command buffer there are actual parameters.
>> Some of those parameters can be references to another memory objects.
>> So, to translate IPAs to PAs we need to map this command buffer,
>> analyze it and so on.
>
>
> So the SMC issued will contain a PA of a page belonging to the guest or Xen?
It will be guest page. But all references to other pages will have
real PAs, so TEE can work with them.

Lets dive into example: hypervisor traps SMC, mediation layer (see
below) can see that there was INVOKE_COMMAND request. There are
address of command buffer in register pair (r1, r2). Mediation layer
changes address in this register pair to real PA of the command
buffer. Then it maps specified page and checks parameters. One of
parameters have type MEMREF, so mediation layer has to change IPA of
specified buffer to PA. Then it issues real SMC call.
After return from SMC it inspects registers and buffer again and
replaces memory references back.

>>>
>>>>>>
>>>>>> I can see only one benefit there - this code will be not in
>>>>>> hypervisor. And there are number of drawbacks:
>>>>>>
>>>>>> Stability: if this userspace demon will crash or get killed by, say,
>>>>>> OOM, we will lose information about all opened sessions, mapped shared
>>>>>> buffers, etc.That would be complete disaster.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I disagree on your statement, you would gain in isolation. If your
>>>>> userspace
>>>>> crashes (because of an emulation bug), you will only loose access to
>>>>> TEE
>>>>> for
>>>>> a bit. If the hypervisor crashes (because of an emulation bug), then
>>>>> you
>>>>> take down the platform. I agree that you lose information when the
>>>>> userspace
>>>>> app is crashing but your platform is still up. Isn't it the most
>>>>> important?
>>>>
>>>>
>>>> This is arguable and depends on what you consider more valuable:
>>>> system security or system stability.
>>>> I'm standing on security point.
>>>
>>>
>>>
>>> How handling SMC in the hypervisor would be more secure? The OP-TEE
>>> support
>>> will introduce code will need to:
>>>         - Whitelist SMC call
>>>         - Altering SMC call to translate an IPA to PA
>>>         - Keep track of session
>>>         - ....
>>> In general, I am quite concern every time someone ask to add emulation in
>>> the hypervisor.  This is increasing the possibility of bug, this is more
>>> true with emulation.
>>
>> It is not an emulation. Actually it is virtualization. It is like
>> hypervisor provides virtual CPU or virtual GIC. There can be virtual
>> TEE as well.
>
>
> We seem to be disagree on terminology here. The virtualization is a generic
> term for creating a virtual resource. This could be done by the hardware or
> by software (aka emulation).
>
> In the case of the GIC, we use both:
>         - emulation for the distributor
>         - HW-assisted for the CPU interface
>
> In your case, you need to mangle the SMC parameters so this is software
> virtualization (aka emulation).
Yep, probably terminology issue there. For me "emulation" is a
imitation of behavior of something. While proposed solution is for
mediation, not for imitation.
Probably we can call it "TEE access mediation" or "mediation layer"?

[...]

>>
>> Also, I hate to ask again, but can we ask some TrustZone guys on how
>> they see interaction between Normal and Secure worlds in presence of
>> hypervisor?
>
>
> This has been asked and I am waiting an answer.
Oh, okay. Thank you.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

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