Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
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 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
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 >> >> 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
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 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
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
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 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
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 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. 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. 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. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
Hello Julien,
Julien Grall writes:
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>>
>> 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 :-)
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'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.
> I have CCed Achin to see he has any vision how this could be interfaced.
>
>>
>> It is possible to add another types in the future.
>>
>> Signed-off-by: Volodymyr Babchuk
>> ---
>>
>> All the patches to optee.c should be merged together. They were
>> split to ease up review. But they depend heavily on each other.
>>
>> Changes from v3:
>>- tee_enabled renamed to tee_type. Currently two types are supported
>> as described in the commit message
>>- Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition
>>
>> Changes from v2:
>>- Use arch.tee_enabled instead of separate domctl
>> ---
>> docs/man/xl.cfg.5.pod.in| 12
>> tools/libxl/libxl.h | 5 +
>> tools/libxl/libxl_arm.c | 13 +
>> tools/libxl/libxl_types.idl | 6 ++
>> tools/xl/xl_parse.c | 9 +
>> 5 files changed, 45 insertions(+)
>>
>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>> index ad81af1ed8..e15981882b 100644
>> --- a/docs/man/xl.cfg.5.pod.in
>> +++ b/docs/man/xl.cfg.5.pod.in
>> @@ -2702,6 +2702,18 @@ Currently, only the "sbsa_uart" model is supported
>> for ARM.
>> =back
>> +=over 4
>> +
>> +=item B
>> +
>> +Set TEE type for the guest. Currently only OP-TEE is supported. If
>> +this option is set to "native", xl will create guest, which can access
>> +native TEE on your system (just make sure that you are using OP-TEE
>> +with virtualization support endabled). Also OP-TEE node will be
>> +emitted into guest's device tree.
>> +
>> +=back
>> +
>> =head3 x86
>> =over 4
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index a38e5cdba2..b24e4141b1 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -273,6 +273,11 @@
>>*/
>> #define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
>> +/*
>> + * libxl_domain_build_info has the arch_arm.tee field.
>> + */
>> +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1
>> +
>> /*
>>* LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
>>* 'soft reset' for domains and there is 'soft_reset' shutdown reason
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index 141e159043..6930d0ab3b 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -89,6 +89,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>> return ERROR_FAIL;
>> }
>> +switch (d_config->b_info.arch_arm.tee) {
>> +case LIBXL_TEE_TYPE_NONE:
>> +config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE;
>> +break;
>> +case LIBXL_TEE_TYPE_NATIVE:
>> +config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NATIVE;
>> +break;
>> +default:
>> +LOG(ERROR, "Unknown TEE type %d",
>> +d_config->b_info.arch_arm.tee);
>> +return ERROR_FAIL;
>> +}
>> +
>> return 0;
>> }
>> diff --git a/tools/libxl/libxl_types.idl
>> b/tools/libxl/libxl_types.idl
>> index b685ac47ac..4f1eb229b8 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -457,6 +457,11 @@ libxl_gic_version = Enumeration("gic_version", [
>> (0x30, "v3")
>> ], init_val
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
Hi Julien,
On Mon, Mar 18, 2019 at 03:49:12PM +, Julien Grall wrote:
> (+ Achin)
>
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
> > From: Volodymyr Babchuk
> >
> > 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?
>
> I have CCed Achin to see he has any vision how this could be interfaced.
Thanks.
Multiple TEEs (or rather Trusted OSs) can coexist on Armv8.3 and earlier. They
will not be isolated but play along nicely.
The intent is that prior to S-EL2 and multiple TOSs, each TOS will migrate to
using the SPCI spec. At this stage, there should be no need for a TOS specific
mediator in the Hypervisor. IOW, there should be a "generic" SPCI
mediator. Maybe, we can add a TEE type 'generic' later to enable access to any
TEE through this generic interface?
Support for multiple TOSs has raised other questions that we are trying to
address e.g. dependencies between them or on guests in Nwd, impact on scheduling
decisions made by Nwd etc. Support for OP-TEE in this patch stack does not need
to answer these just yet it seems. It is more likely that we will have to tackle
support for multiple TEEs afresh rather than treating it as an extension of
support for a specific TOS.
Happy to discuss further and I hope this helps in some way.
cheers,
Achin
>
> >
> > It is possible to add another types in the future.
> >
> > Signed-off-by: Volodymyr Babchuk
> > ---
> >
> > All the patches to optee.c should be merged together. They were
> > split to ease up review. But they depend heavily on each other.
> >
> > Changes from v3:
> >- tee_enabled renamed to tee_type. Currently two types are supported
> > as described in the commit message
> >- Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition
> >
> > Changes from v2:
> >- Use arch.tee_enabled instead of separate domctl
> > ---
> > docs/man/xl.cfg.5.pod.in| 12
> > tools/libxl/libxl.h | 5 +
> > tools/libxl/libxl_arm.c | 13 +
> > tools/libxl/libxl_types.idl | 6 ++
> > tools/xl/xl_parse.c | 9 +
> > 5 files changed, 45 insertions(+)
> >
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index ad81af1ed8..e15981882b 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@ -2702,6 +2702,18 @@ Currently, only the "sbsa_uart" model is supported
> > for ARM.
> > =back
> > +=over 4
> > +
> > +=item B
> > +
> > +Set TEE type for the guest. Currently only OP-TEE is supported. If
> > +this option is set to "native", xl will create guest, which can access
> > +native TEE on your system (just make sure that you are using OP-TEE
> > +with virtualization support endabled). Also OP-TEE node will be
> > +emitted into guest's device tree.
> > +
> > +=back
> > +
> > =head3 x86
> > =over 4
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index a38e5cdba2..b24e4141b1 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -273,6 +273,11 @@
> >*/
> > #define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
> > +/*
> > + * libxl_domain_build_info has the arch_arm.tee field.
> > + */
> > +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1
> > +
> > /*
> >* LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
> >* 'soft reset' for domains and there is 'soft_reset' shutdown reason
> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> > index 141e159043..6930d0ab3b 100644
> > --- a/tools/libxl/libxl_arm.c
> > +++ b/tools/libxl/libxl_arm.c
> > @@ -89,6 +89,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> > return ERROR_FAIL;
> > }
> > +switch (d_config->b_info.arch_arm.tee) {
> > +case LIBXL_TEE_TYPE_NONE:
> > +config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE;
> > +break;
> > +case LIBXL_TEE_TYPE_NATIVE:
> > +config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NATIVE;
> > +break;
> > +default:
> > +LOG(ERROR, "Unknown TEE type %d",
> > +d_config->b_info.arch_arm.tee);
> > +return ERROR_FAIL;
> > +}
> > +
> > return 0;
> > }
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index b685ac47ac..4f1eb229b8 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -457,6 +457,11 @@ libxl_gic_version = Enumeration("gic_version", [
> > (0x30, "v3")
> > ], init_val = "LIBXL_GIC_VERSION_DEFAULT")
> > +libxl_tee_type = Enumeration("tee_type", [
> > +(0, "none"),
> > +
Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
(+ Achin)
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
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?
I have CCed Achin to see he has any vision how this could be interfaced.
It is possible to add another types in the future.
Signed-off-by: Volodymyr Babchuk
---
All the patches to optee.c should be merged together. They were
split to ease up review. But they depend heavily on each other.
Changes from v3:
- tee_enabled renamed to tee_type. Currently two types are supported
as described in the commit message
- Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition
Changes from v2:
- Use arch.tee_enabled instead of separate domctl
---
docs/man/xl.cfg.5.pod.in| 12
tools/libxl/libxl.h | 5 +
tools/libxl/libxl_arm.c | 13 +
tools/libxl/libxl_types.idl | 6 ++
tools/xl/xl_parse.c | 9 +
5 files changed, 45 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ad81af1ed8..e15981882b 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2702,6 +2702,18 @@ Currently, only the "sbsa_uart" model is supported for
ARM.
=back
+=over 4
+
+=item B
+
+Set TEE type for the guest. Currently only OP-TEE is supported. If
+this option is set to "native", xl will create guest, which can access
+native TEE on your system (just make sure that you are using OP-TEE
+with virtualization support endabled). Also OP-TEE node will be
+emitted into guest's device tree.
+
+=back
+
=head3 x86
=over 4
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a38e5cdba2..b24e4141b1 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,11 @@
*/
#define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
+/*
+ * libxl_domain_build_info has the arch_arm.tee field.
+ */
+#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1
+
/*
* LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
* 'soft reset' for domains and there is 'soft_reset' shutdown reason
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 141e159043..6930d0ab3b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -89,6 +89,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
return ERROR_FAIL;
}
+switch (d_config->b_info.arch_arm.tee) {
+case LIBXL_TEE_TYPE_NONE:
+config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE;
+break;
+case LIBXL_TEE_TYPE_NATIVE:
+config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NATIVE;
+break;
+default:
+LOG(ERROR, "Unknown TEE type %d",
+d_config->b_info.arch_arm.tee);
+return ERROR_FAIL;
+}
+
return 0;
}
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b685ac47ac..4f1eb229b8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -457,6 +457,11 @@ libxl_gic_version = Enumeration("gic_version", [
(0x30, "v3")
], init_val = "LIBXL_GIC_VERSION_DEFAULT")
+libxl_tee_type = Enumeration("tee_type", [
+(0, "none"),
+(1, "native")
+], init_val = "LIBXL_TEE_TYPE_NONE")
+
libxl_rdm_reserve = Struct("rdm_reserve", [
("strategy",libxl_rdm_reserve_strategy),
("policy", libxl_rdm_reserve_policy),
@@ -615,6 +620,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
("vuart", libxl_vuart_type),
+ ("tee", libxl_tee_type),
AFAICT, TEE also exists on other architecture. So I am wondering whether this
field should be moved out of arch_arm?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg
From: Volodymyr Babchuk
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.
It is possible to add another types in the future.
Signed-off-by: Volodymyr Babchuk
---
All the patches to optee.c should be merged together. They were
split to ease up review. But they depend heavily on each other.
Changes from v3:
- tee_enabled renamed to tee_type. Currently two types are supported
as described in the commit message
- Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition
Changes from v2:
- Use arch.tee_enabled instead of separate domctl
---
docs/man/xl.cfg.5.pod.in| 12
tools/libxl/libxl.h | 5 +
tools/libxl/libxl_arm.c | 13 +
tools/libxl/libxl_types.idl | 6 ++
tools/xl/xl_parse.c | 9 +
5 files changed, 45 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ad81af1ed8..e15981882b 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2702,6 +2702,18 @@ Currently, only the "sbsa_uart" model is supported for
ARM.
=back
+=over 4
+
+=item B
+
+Set TEE type for the guest. Currently only OP-TEE is supported. If
+this option is set to "native", xl will create guest, which can access
+native TEE on your system (just make sure that you are using OP-TEE
+with virtualization support endabled). Also OP-TEE node will be
+emitted into guest's device tree.
+
+=back
+
=head3 x86
=over 4
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a38e5cdba2..b24e4141b1 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,11 @@
*/
#define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
+/*
+ * libxl_domain_build_info has the arch_arm.tee field.
+ */
+#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1
+
/*
* LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
* 'soft reset' for domains and there is 'soft_reset' shutdown reason
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 141e159043..6930d0ab3b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -89,6 +89,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
return ERROR_FAIL;
}
+switch (d_config->b_info.arch_arm.tee) {
+case LIBXL_TEE_TYPE_NONE:
+config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE;
+break;
+case LIBXL_TEE_TYPE_NATIVE:
+config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NATIVE;
+break;
+default:
+LOG(ERROR, "Unknown TEE type %d",
+d_config->b_info.arch_arm.tee);
+return ERROR_FAIL;
+}
+
return 0;
}
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b685ac47ac..4f1eb229b8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -457,6 +457,11 @@ libxl_gic_version = Enumeration("gic_version", [
(0x30, "v3")
], init_val = "LIBXL_GIC_VERSION_DEFAULT")
+libxl_tee_type = Enumeration("tee_type", [
+(0, "none"),
+(1, "native")
+], init_val = "LIBXL_TEE_TYPE_NONE")
+
libxl_rdm_reserve = Struct("rdm_reserve", [
("strategy",libxl_rdm_reserve_strategy),
("policy", libxl_rdm_reserve_policy),
@@ -615,6 +620,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
("vuart", libxl_vuart_type),
+ ("tee", libxl_tee_type),
])),
# Alternate p2m is not bound to any architecture or guest type, as it is
# supported by x86 HVM and ARM support is planned.
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 352cd214dd..c27e7ae1f0 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2690,6 +2690,15 @@ skip_usbdev:
}
}
+if (!xlu_cfg_get_string (config, "tee", , 1)) {
+e = libxl_tee_type_from_string(buf, _info->arch_arm.tee);
+if (e) {
+fprintf(stderr,
+"Unknown tee \"%s\" specified\n", buf);
+exit(-ERROR_FAIL);
+}
+}
+
parse_vkb_list(config, d_config);
xlu_cfg_destroy(config);
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
