[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.