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.babc...@gmail.com> >>>>>> >>>>>> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel