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

[Julien Grall <julien.grall@xxxxxxx>]

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 :).
> > > > 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.
From my understanding, TEE [1] seems to be a rather generic name with some 
supports on various architectures. I can't rule out that other architectures 
(current or future) will not want to provide guest TEE.
So I think the common option is the best here.

Cheers,

[1] https://en.wikipedia.org/wiki/Trusted_execution_environment

--
Julien Grall

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