Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

Hi Julien,

Julien Grall writes:

> Hi,
>
> On 20/03/2019 17:01, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> On 20/03/2019 15:27, Volodymyr Babchuk wrote:
>>>>
>>>> Hello Julien,
>>>>
>>>> Julien Grall writes:
>>>>
>>>>> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>>>>>> From: Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>
>>>>>>
>>>>>> This enumeration controls TEE type for a domain. Currently there is
>>>>>> two possible options: either 'none' or 'native'.
>>>>>>
>>>>>> 'none' is the default value and it basically disables TEE support at
>>>>>> all.
>>>>>>
>>>>>> 'native' enables access to a "real" TEE installed on a platform.
>>>>>
>>>>> I am aware I made that suggestion. But I think the naming is not ideal
>>>>> between the user and the toolstack. The question is how this is going
>>>>> to fit with the S-EL2 feature where multiple TEE can run together?
>>>> You see, support for S-EL2 or support for multiple TEEs is a much broader
>>>> topic. For me, naming for configuration option is the least important
>>>> thing in this case :-)
>>>
>>> Naming exposed to users are hard to remove. If the naming is too
>>> ambiguous, then we will have to introduce a new option later on. This
>>> is not very ideal, so it would be better if we can find something
>>> different.
>>>
>>>>
>>>> Right there is no clear vision how it will ever work. I scanned through
>>>> SPCI spec and I already have a couple of questions. I need to study it
>>>> harder to make serious statements, but I already see that current
>>>> mediator framework will hardly fit into SPCI stuff. Frankly, I have
>>>> concerns that OP-TEE (or any other existing TEE) will be compatible
>>>> with SPCI-enabled systems without major rework. So, we will need to do
>>>> big overhaul anyways, when there will appear first SPCI-compatible TEEs and
>>>> secure hypervisors.
>>>>
>>>> AFAIK, there is no ARMv8.4 platforms, no S-EL2 hypervisors and so on. It
>>>> will take at least couple of years before S-EL2 will hit the market. So
>>>> in my opinion it is too early to make any assumptions on how to support
>>>> all this in Xen. Lets stick to the current matters.
>>>
>>> I am fully aware that more work will need to be done with S-EL2. I am
>>> not expecting you (or anyone else here) to come with the
>>> implementation now. My point is the naming should be chosen so it
>>> prevents ambiguity with whatever we know will come up in the future.
>>>
>>>>
>>>> I'm not insisting on "native". But I can't invent something better right
>>>> now. Probably, SPCI-enabled TEE also will be considered "native" as
>>>> opposed to, say, "emulated". >
>>>> As I said, I can't come with anything better than "native". But I'm open
>>>> to any suggestions.
>>>
>>> Well one solution is to ditch "native" and name it "optee". By giving
>>> the name you avoid ambiguity. If we ever have multiple op-tee instance
>>> running, then it could easily be extend with a comma. So you allow
>>> backward compatibility.
>>
>> I considered this. But If I remember right, idea was to query Xen about
>> available TEE, and configure guest in the appropriate way. So "native"
>> (or some other generic way) could be used for OP-TEE, Google Trusty or
>> any other TEE, without changing guest configuration.
>>
>> Using "optee" will cause explicit configuration for OP-TEE only. I can't
>> say that this is good or bad. It just different. Do you think that would
>> be better approach?
>
> You have 2 different cases to take into account:
>    - A guest is able to deal with all supported Trusted OS. So
> "native" will let the toolstack query the current Trusted OS and
> expose it to the guest.
>    - A guest can only deal with a specific Trusted OS. In that case,
> the user might want to specify in the configuration the expected
> Trusted OS so it can't boot if not available.
>
> What I suggest is deferring the former case until we have another TEE
> in hand. Maybe at that time, we will have a better naming :).

Okay, so summarizing this up, you are proposing to use "optee". Am I got
you right?

-- 
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel