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

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 4/5/19 11:25 AM, Volodymyr Babchuk wrote:
> 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?
I am suggesting 'tee = "optee"' for now.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel