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

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

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?

>
>>> AFAICT, TEE also exists on other architecture. So I am wondering
>>> whether this field should be moved out of arch_arm?
>> In v3 thread you asked if I see any use for x86. Because in that version
>> this option was in common section. Honestly, I don't see any use there,
>> because I have no idea how this can be implemented on x86.
>
> On the v3, I pointed out that the documentation was in Arm section but
> the code was in common. When I asked a question, it does not mean I am
> not happy with it. It only means I am trying to understand your choice
> so I can make my mind on it. Sadly, you left it unanswered until now.

Oh, I see. My intention was to put this into ARM section. So, I
documented it in the right way, but did mistake, putting it into wrong
place in the xl/libxl code. It was my first patch to toolstack, so I
just didn't knew the right place.

> In this context, I am not asking you how this is going to be
> implemented but whether this option could potentially be used in the
> future for other architecture (e.g x86, RISC-V...). For instance, the
> option "device_tree" is part for common options despite it is only
> implemented on Arm.

I believe to your experience there. If you think it is better to move
this into common code - I'll do this.

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