Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Chris, On Tue, 6 Nov 2018 at 07:23, Chris Co wrote: > > Hi Sumit, > > > -Original Message- > > From: Sumit Garg > > > > Hi Chris, > > > > On Sat, 3 Nov 2018 at 05:25, Chris Co wrote: > > > > > > Hi Sumit, > > > > > > > -Original Message- > > > > From: Sumit Garg > > > > > > > > + OP-TEE ML. > > > > > > > > On Fri, 2 Nov 2018 at 06:11, Chris Co > > wrote: > > > > > > > > > > Hi Sumit, > > > > > > > > > > Our full OpteeClientPkg has: > > > > > - Our OpteeClientAPI implementation. I was monitoring the merge > > > > > progress > > > > on OpteeLib and will look into moving over now that it is available. > > > > > - The fTPM and AuthVar TA binaries. In our current design, the TA > > > > > binaries > > > > are loaded at runtime. We could host the binaries themselves > > > > elsewhere on the filesystem, but we do not want these binaries as > > > > early/pseudo TAs. Is there a plan for OpteeLib to support loading full > > > > TAs? > > > > > > > > Early TAs [1] are basically full TAs only, running in Secure EL0 mode. > > > > So instead of loading TA from normal world file-system, they are > > > > linked into a special data section in the OP-TEE core blob. > > > > > > > > Also I don't think loading TAs dynamically especially during boot > > > > makes much sense due to following reasons: > > > > 1. Increased boot time. > > > > 2. Fixed TAs like in your case which could be linked as early TAs as > > > > well. > > > > > > > > > > We prefer to load TAs dynamically for a more flexible servicing story. My > > understanding is that Early TAs are coupled with the OP-TEE binary itself, > > so > > to update an Early TA, a new OP-TEE binary would need to be created and > > pushed. We want to avoid rolling a new OP-TEE and only update the TA > > binary in this scenario. > > > > > > > Are you referring to run-time updates on the device in the field? If this > > is the > > case then how do you think to update TAs, is it via some custom capsule > > update method? > > > > Yes, run-time TA updates. Currently, our fTPM and Authvar TAs get packaged > inside our UEFI binary. So an update to a TA means a UEFI update via firmware > capsule. > The discussion of these TA binaries living on the filesystem were ideas we > were discussing internally but are not fully baked or committed to. > I would suggest you to keep TAs as part of firmware only (UEFI binary in your case). > > I do consider these TAs used during boot as essential secure services > > provided > > by the secure firmware (OP-TEE in this case). So these TAs should be part of > > firmware itself and updates for them should come through firmware capsule > > updates only. > > > > I agree in principle and I think I see where the misalignment is, mostly > coming from my end. > The security guarantees (termed TCPS) we want to provide on the current > hardware we support (NXP i.MX6), mean OP-TEE becomes prohibitively difficult > to update. This is due to a hardware resource limitation (not enough fuse > space). If this limitation were not present, we could freely update OP-TEE > and package these TAs as EarlyTAs. > Now I understand where this requirement came from. It seems to be a valid scenario where secure non-volatile memory is limited on a particular platform. > Info on TCPS (whitepaper at bottom of post) - > https://www.microsoft.com/en-us/microsoft-365/blog/2018/04/24/trusted-cyber-physical-systems-looks-to-protect-your-critical-infrastructure-from-modern-threats-in-the-world-of-iot/ > > I'm not sure how you want to handle this from an OpteeLib vs custom platform > package perspective. > We could add this dynamic TA loading support in OpteeLib as optional, enabled in a platform specific way. Regards, Sumit > > > > And you mentioned filesystem, are you referring to root filesystem? > > > > > > > > > > We have not implemented this yet, but we were thinking to have the TA > > binaries present in the EFI partition. > > > > > > > AFAIK, EFI partition is shared among Linux and UEFI. This provides Linux > > access to secure firmware TAs that could be a security concern (denial of > > service could be one of them). > > > > Note - we are booting Windows, though your point here is still valid. The TAs > living in the filesystem is not what is implemented today. It was an idea we > were discussing internally. > > > > > > - We have two client drivers: a firmware TPM TA driver and an > > > > authenticated variable TA driver. These talk through the > > > > tee-supplicant to their respective TAs. > > > > > > > > > > > > > Here from tee-supplicant apart from loading TAs, what other services > > > > are you expecting? If you are looking for secure storage via RPMB, > > > > that could be an enhancement to OpteeLib adding corresponding RPC > > handling here [2]. > > > > > > > > > > For RPC handling, we are looking for the following callback support: > > > - OPTEE_SMC_RPC_FUNC_ALLOC > > > - OPTEE_SMC_RPC_FUNC_FREE > > > - OPTEE_SMC_RPC_FUNC_CMD > >
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Sumit, > -Original Message- > From: Sumit Garg > > Hi Chris, > > On Sat, 3 Nov 2018 at 05:25, Chris Co wrote: > > > > Hi Sumit, > > > > > -Original Message- > > > From: Sumit Garg > > > > > > + OP-TEE ML. > > > > > > On Fri, 2 Nov 2018 at 06:11, Chris Co > wrote: > > > > > > > > Hi Sumit, > > > > > > > > Our full OpteeClientPkg has: > > > > - Our OpteeClientAPI implementation. I was monitoring the merge > > > > progress > > > on OpteeLib and will look into moving over now that it is available. > > > > - The fTPM and AuthVar TA binaries. In our current design, the TA > > > > binaries > > > are loaded at runtime. We could host the binaries themselves > > > elsewhere on the filesystem, but we do not want these binaries as > > > early/pseudo TAs. Is there a plan for OpteeLib to support loading full > > > TAs? > > > > > > Early TAs [1] are basically full TAs only, running in Secure EL0 mode. > > > So instead of loading TA from normal world file-system, they are > > > linked into a special data section in the OP-TEE core blob. > > > > > > Also I don't think loading TAs dynamically especially during boot > > > makes much sense due to following reasons: > > > 1. Increased boot time. > > > 2. Fixed TAs like in your case which could be linked as early TAs as well. > > > > > > > We prefer to load TAs dynamically for a more flexible servicing story. My > understanding is that Early TAs are coupled with the OP-TEE binary itself, so > to update an Early TA, a new OP-TEE binary would need to be created and > pushed. We want to avoid rolling a new OP-TEE and only update the TA > binary in this scenario. > > > > Are you referring to run-time updates on the device in the field? If this is > the > case then how do you think to update TAs, is it via some custom capsule > update method? > Yes, run-time TA updates. Currently, our fTPM and Authvar TAs get packaged inside our UEFI binary. So an update to a TA means a UEFI update via firmware capsule. The discussion of these TA binaries living on the filesystem were ideas we were discussing internally but are not fully baked or committed to. > I do consider these TAs used during boot as essential secure services provided > by the secure firmware (OP-TEE in this case). So these TAs should be part of > firmware itself and updates for them should come through firmware capsule > updates only. > I agree in principle and I think I see where the misalignment is, mostly coming from my end. The security guarantees (termed TCPS) we want to provide on the current hardware we support (NXP i.MX6), mean OP-TEE becomes prohibitively difficult to update. This is due to a hardware resource limitation (not enough fuse space). If this limitation were not present, we could freely update OP-TEE and package these TAs as EarlyTAs. Info on TCPS (whitepaper at bottom of post) - https://www.microsoft.com/en-us/microsoft-365/blog/2018/04/24/trusted-cyber-physical-systems-looks-to-protect-your-critical-infrastructure-from-modern-threats-in-the-world-of-iot/ I'm not sure how you want to handle this from an OpteeLib vs custom platform package perspective. > > > And you mentioned filesystem, are you referring to root filesystem? > > > > > > > We have not implemented this yet, but we were thinking to have the TA > binaries present in the EFI partition. > > > > AFAIK, EFI partition is shared among Linux and UEFI. This provides Linux > access to secure firmware TAs that could be a security concern (denial of > service could be one of them). > Note - we are booting Windows, though your point here is still valid. The TAs living in the filesystem is not what is implemented today. It was an idea we were discussing internally. > > > > - We have two client drivers: a firmware TPM TA driver and an > > > authenticated variable TA driver. These talk through the > > > tee-supplicant to their respective TAs. > > > > > > > > > > Here from tee-supplicant apart from loading TAs, what other services > > > are you expecting? If you are looking for secure storage via RPMB, > > > that could be an enhancement to OpteeLib adding corresponding RPC > handling here [2]. > > > > > > > For RPC handling, we are looking for the following callback support: > > - OPTEE_SMC_RPC_FUNC_ALLOC > > - OPTEE_SMC_RPC_FUNC_FREE > > - OPTEE_SMC_RPC_FUNC_CMD > > - OPTEE_MSG_RPC_CMD_LOAD_TA > > Please see above comments for this. > > > - OPTEE_MSG_RPC_CMD_RPMB > > - OPTEE_MSG_RPC_CMD_GET_TIME > > Can you share the usage of OPTEE_MSG_RPC_CMD_GET_TIME? AFAIK, this is > used to get REE time from OP-TEE. > I dug further and found that this was being used in our fTPM TA for debug logs. It has since been deprecated so we do not need this RPC command. > > - OPTEE_MSG_RPC_CMD_SHM_ALLOC > > - OPTEE_MSG_RPC_CMD_SHM_FREE > > - OPTEE_MSG_RPC_CMD_WAIT_QUEUE > > I don't think we need OPTEE_MSG_RPC_CMD_WAIT_QUEUE implementation > in UEFI as its a single threaded
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Chris, On Sat, 3 Nov 2018 at 05:25, Chris Co wrote: > > Hi Sumit, > > > -Original Message- > > From: Sumit Garg > > Sent: Thursday, November 1, 2018 10:24 PM > > To: Chris Co > > Cc: Leif Lindholm ; edk2-devel@lists.01.org; Ard > > Biesheuvel ; Michael D Kinney > > ; tee-...@lists.linaro.org > > Subject: Re: [PATCH edk2-platforms 01/27] Platform/Microsoft: Add > > OpteeClientPkg dec > > > > + OP-TEE ML. > > > > On Fri, 2 Nov 2018 at 06:11, Chris Co wrote: > > > > > > Hi Sumit, > > > > > > Our full OpteeClientPkg has: > > > - Our OpteeClientAPI implementation. I was monitoring the merge progress > > on OpteeLib and will look into moving over now that it is available. > > > - The fTPM and AuthVar TA binaries. In our current design, the TA binaries > > are loaded at runtime. We could host the binaries themselves elsewhere on > > the filesystem, but we do not want these binaries as early/pseudo TAs. Is > > there a plan for OpteeLib to support loading full TAs? > > > > Early TAs [1] are basically full TAs only, running in Secure EL0 mode. > > So instead of loading TA from normal world file-system, they are linked > > into a > > special data section in the OP-TEE core blob. > > > > Also I don't think loading TAs dynamically especially during boot makes much > > sense due to following reasons: > > 1. Increased boot time. > > 2. Fixed TAs like in your case which could be linked as early TAs as well. > > > > We prefer to load TAs dynamically for a more flexible servicing story. My > understanding is that Early TAs are coupled with the OP-TEE binary itself, so > to update an Early TA, a new OP-TEE binary would need to be created and > pushed. We want to avoid rolling a new OP-TEE and only update the TA binary > in this scenario. > Are you referring to run-time updates on the device in the field? If this is the case then how do you think to update TAs, is it via some custom capsule update method? I do consider these TAs used during boot as essential secure services provided by the secure firmware (OP-TEE in this case). So these TAs should be part of firmware itself and updates for them should come through firmware capsule updates only. > > And you mentioned filesystem, are you referring to root filesystem? > > > > We have not implemented this yet, but we were thinking to have the TA > binaries present in the EFI partition. > AFAIK, EFI partition is shared among Linux and UEFI. This provides Linux access to secure firmware TAs that could be a security concern (denial of service could be one of them). > > > - We have two client drivers: a firmware TPM TA driver and an > > authenticated variable TA driver. These talk through the tee-supplicant to > > their respective TAs. > > > > > > > Here from tee-supplicant apart from loading TAs, what other services are you > > expecting? If you are looking for secure storage via RPMB, that could be an > > enhancement to OpteeLib adding corresponding RPC handling here [2]. > > > > For RPC handling, we are looking for the following callback support: > - OPTEE_SMC_RPC_FUNC_ALLOC > - OPTEE_SMC_RPC_FUNC_FREE > - OPTEE_SMC_RPC_FUNC_CMD > - OPTEE_MSG_RPC_CMD_LOAD_TA Please see above comments for this. > - OPTEE_MSG_RPC_CMD_RPMB > - OPTEE_MSG_RPC_CMD_GET_TIME Can you share the usage of OPTEE_MSG_RPC_CMD_GET_TIME? AFAIK, this is used to get REE time from OP-TEE. > - OPTEE_MSG_RPC_CMD_SHM_ALLOC > - OPTEE_MSG_RPC_CMD_SHM_FREE > - OPTEE_MSG_RPC_CMD_WAIT_QUEUE I don't think we need OPTEE_MSG_RPC_CMD_WAIT_QUEUE implementation in UEFI as its a single threaded execution flow on boot core. BTW, I am not sure if I could get time to work on RPC handling anytime soon. So patches are welcome and I am happy to review them. Regards, Sumit > > Thanks, > Chris > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > > om%2FOP- > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fdocumentation%2Foptee_design.md > > %23early-trusted- > > applicationsdata=02%7C01%7CChristopher.Co%40microsoft.com%7C4a > > 7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd011db47% > > 7C1%7C0%7C636767330779998429sdata=yaDWw5Z6yuux1o89kxzbknVp > > b%2B1OHUagbB%2FOGS4dAcU%3Dreserved=0 > > [2] > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FLibrary%2FOpteeL > > ib%2FOptee.c%23L147data=02%7C01%7CChristopher.Co%40microsoft.c > > om%7C4a7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C636767330779998429sdata=Lsplb1L7Ugd2C6cXG > > 8gBo40Ei8UQPtIA7fNEDL1t%2Fbg%3Dreserved=0 > > > > Regards, > > Sumit > > > > > Chris > > > > > > > -Original Message- > > > > From: Sumit Garg > > > > Sent: Thursday, November 1, 2018 3:55 AM > > > > To: Chris Co ; Leif Lindholm > > > > > > > > Cc: edk2-devel@lists.01.org; Ard Biesheuvel > > > > ; Michael D Kinney > > > > > > > > Subject: Re: [PATCH edk2-platforms 01/27]
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Sumit, > -Original Message- > From: Sumit Garg > Sent: Thursday, November 1, 2018 10:24 PM > To: Chris Co > Cc: Leif Lindholm ; edk2-devel@lists.01.org; Ard > Biesheuvel ; Michael D Kinney > ; tee-...@lists.linaro.org > Subject: Re: [PATCH edk2-platforms 01/27] Platform/Microsoft: Add > OpteeClientPkg dec > > + OP-TEE ML. > > On Fri, 2 Nov 2018 at 06:11, Chris Co wrote: > > > > Hi Sumit, > > > > Our full OpteeClientPkg has: > > - Our OpteeClientAPI implementation. I was monitoring the merge progress > on OpteeLib and will look into moving over now that it is available. > > - The fTPM and AuthVar TA binaries. In our current design, the TA binaries > are loaded at runtime. We could host the binaries themselves elsewhere on > the filesystem, but we do not want these binaries as early/pseudo TAs. Is > there a plan for OpteeLib to support loading full TAs? > > Early TAs [1] are basically full TAs only, running in Secure EL0 mode. > So instead of loading TA from normal world file-system, they are linked into a > special data section in the OP-TEE core blob. > > Also I don't think loading TAs dynamically especially during boot makes much > sense due to following reasons: > 1. Increased boot time. > 2. Fixed TAs like in your case which could be linked as early TAs as well. > We prefer to load TAs dynamically for a more flexible servicing story. My understanding is that Early TAs are coupled with the OP-TEE binary itself, so to update an Early TA, a new OP-TEE binary would need to be created and pushed. We want to avoid rolling a new OP-TEE and only update the TA binary in this scenario. > And you mentioned filesystem, are you referring to root filesystem? > We have not implemented this yet, but we were thinking to have the TA binaries present in the EFI partition. > > - We have two client drivers: a firmware TPM TA driver and an > authenticated variable TA driver. These talk through the tee-supplicant to > their respective TAs. > > > > Here from tee-supplicant apart from loading TAs, what other services are you > expecting? If you are looking for secure storage via RPMB, that could be an > enhancement to OpteeLib adding corresponding RPC handling here [2]. > For RPC handling, we are looking for the following callback support: - OPTEE_SMC_RPC_FUNC_ALLOC - OPTEE_SMC_RPC_FUNC_FREE - OPTEE_SMC_RPC_FUNC_CMD - OPTEE_MSG_RPC_CMD_LOAD_TA - OPTEE_MSG_RPC_CMD_RPMB - OPTEE_MSG_RPC_CMD_GET_TIME - OPTEE_MSG_RPC_CMD_SHM_ALLOC - OPTEE_MSG_RPC_CMD_SHM_FREE - OPTEE_MSG_RPC_CMD_WAIT_QUEUE Thanks, Chris > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > om%2FOP- > TEE%2Foptee_os%2Fblob%2Fmaster%2Fdocumentation%2Foptee_design.md > %23early-trusted- > applicationsdata=02%7C01%7CChristopher.Co%40microsoft.com%7C4a > 7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C636767330779998429sdata=yaDWw5Z6yuux1o89kxzbknVp > b%2B1OHUagbB%2FOGS4dAcU%3Dreserved=0 > [2] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FLibrary%2FOpteeL > ib%2FOptee.c%23L147data=02%7C01%7CChristopher.Co%40microsoft.c > om%7C4a7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C636767330779998429sdata=Lsplb1L7Ugd2C6cXG > 8gBo40Ei8UQPtIA7fNEDL1t%2Fbg%3Dreserved=0 > > Regards, > Sumit > > > Chris > > > > > -Original Message- > > > From: Sumit Garg > > > Sent: Thursday, November 1, 2018 3:55 AM > > > To: Chris Co ; Leif Lindholm > > > > > > Cc: edk2-devel@lists.01.org; Ard Biesheuvel > > > ; Michael D Kinney > > > > > > Subject: Re: [PATCH edk2-platforms 01/27] Platform/Microsoft: Add > > > OpteeClientPkg dec > > > > > > Hi Christopher, > > > > > > Optee Client library has recently been merged to edk2 source code. > > > It tries to provide a generic interface [1] to OP-TEE based trusted > > > applications (pseudo/early). > > > > > > AFAIK, you don't need any platform specific hook in client interface > > > to work with upstream OP-TEE. So instead you should use Optee library. > > > > > > [1] > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.c > > > > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FInclude%2FLibrary > > > > %2FOpteeLib.hdata=02%7C01%7CChristopher.Co%40microsoft.com%7C > > > > c19b84ef7f8f4213424108d63fe88f66%7C72f988bf86f141af91ab2d7cd011db47 > > > > %7C1%7C0%7C63675404786500sdata=m24akbKtoyCERVN77meoSU > > > H6E%2Bpf8W2P5MF7nvU5y7I%3Dreserved=0 > > > > > > Regards, > > > Sumit > > > > > > On Thu, 1 Nov 2018 at 02:13, Leif Lindholm > wrote: > > > > > > > > +Sumit (just to loop you two together). Is there anything > > > > +Microsoft > > > > platform specific about what will go in here? > > > > > > > > / > > > > Leif > > > > > > > > On Fri, Sep 21, 2018 at 08:25:53AM +, Chris Co wrote: > > > > > On Windows IoT Core devices with ARM TrustZone
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
+ OP-TEE ML. On Fri, 2 Nov 2018 at 06:11, Chris Co wrote: > > Hi Sumit, > > Our full OpteeClientPkg has: > - Our OpteeClientAPI implementation. I was monitoring the merge progress on > OpteeLib and will look into moving over now that it is available. > - The fTPM and AuthVar TA binaries. In our current design, the TA binaries > are loaded at runtime. We could host the binaries themselves elsewhere on the > filesystem, but we do not want these binaries as early/pseudo TAs. Is there a > plan for OpteeLib to support loading full TAs? Early TAs [1] are basically full TAs only, running in Secure EL0 mode. So instead of loading TA from normal world file-system, they are linked into a special data section in the OP-TEE core blob. Also I don't think loading TAs dynamically especially during boot makes much sense due to following reasons: 1. Increased boot time. 2. Fixed TAs like in your case which could be linked as early TAs as well. And you mentioned filesystem, are you referring to root filesystem? > - We have two client drivers: a firmware TPM TA driver and an authenticated > variable TA driver. These talk through the tee-supplicant to their respective > TAs. > Here from tee-supplicant apart from loading TAs, what other services are you expecting? If you are looking for secure storage via RPMB, that could be an enhancement to OpteeLib adding corresponding RPC handling here [2]. [1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md#early-trusted-applications [2] https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/OpteeLib/Optee.c#L147 Regards, Sumit > Chris > > > -Original Message- > > From: Sumit Garg > > Sent: Thursday, November 1, 2018 3:55 AM > > To: Chris Co ; Leif Lindholm > > > > Cc: edk2-devel@lists.01.org; Ard Biesheuvel ; > > Michael D Kinney > > Subject: Re: [PATCH edk2-platforms 01/27] Platform/Microsoft: Add > > OpteeClientPkg dec > > > > Hi Christopher, > > > > Optee Client library has recently been merged to edk2 source code. It tries > > to > > provide a generic interface [1] to OP-TEE based trusted applications > > (pseudo/early). > > > > AFAIK, you don't need any platform specific hook in client interface to work > > with upstream OP-TEE. So instead you should use Optee library. > > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FInclude%2FLibrary > > %2FOpteeLib.hdata=02%7C01%7CChristopher.Co%40microsoft.com%7C > > c19b84ef7f8f4213424108d63fe88f66%7C72f988bf86f141af91ab2d7cd011db47 > > %7C1%7C0%7C63675404786500sdata=m24akbKtoyCERVN77meoSU > > H6E%2Bpf8W2P5MF7nvU5y7I%3Dreserved=0 > > > > Regards, > > Sumit > > > > On Thu, 1 Nov 2018 at 02:13, Leif Lindholm wrote: > > > > > > +Sumit (just to loop you two together). Is there anything Microsoft > > > platform specific about what will go in here? > > > > > > / > > > Leif > > > > > > On Fri, Sep 21, 2018 at 08:25:53AM +, Chris Co wrote: > > > > On Windows IoT Core devices with ARM TrustZone capabilities, > > > > EDK2 runs in normal world and we use OP-TEE to execute secure world > > > > operations. The overall package will contain client-side support to > > > > invoke EDK2 services implemented as OP-TEE trusted applications that > > > > run in secure world. > > > > > > > > This commit adds the initial dec file to add some PCD settings > > > > needed by other packages. > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > Signed-off-by: Christopher Co > > > > Cc: Ard Biesheuvel > > > > Cc: Leif Lindholm > > > > Cc: Michael D Kinney > > > > --- > > > > Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec | 49 > > > > > > > > 1 file changed, 49 insertions(+) > > > > > > > > diff --git a/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec > > > > b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec > > > > new file mode 100644 > > > > index ..4752eab39ce3 > > > > --- /dev/null > > > > +++ b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec > > > > @@ -0,0 +1,49 @@ > > > > +## @file > > > > +# > > > > +# OP-TEE client package > > > > +# > > > > +# OP-TEE client package contains the client-side interface to invoke > > > > OP- > > TEE TAs. > > > > +# Certain EDKII services are implemented in Trusted Applications > > > > +running in # the secure world OP-TEE OS. > > > > +# > > > > +# Copyright (c) 2018 Microsoft Corporation. All rights reserved. > > > > +# > > > > +# This program and the accompanying materials # are licensed and > > > > +made available under the terms and conditions of the BSD License # > > > > +which accompanies this distribution. The full text of the license > > > > +may be found at # > > > > +https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope > > > > +nsource.org%2Flicenses%2Fbsd- > > license.phpdata=02%7C01%7CChristo > > > > > >
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Sumit,
Our full OpteeClientPkg has:
- Our OpteeClientAPI implementation. I was monitoring the merge progress on
OpteeLib and will look into moving over now that it is available.
- The fTPM and AuthVar TA binaries. In our current design, the TA binaries are
loaded at runtime. We could host the binaries themselves elsewhere on the
filesystem, but we do not want these binaries as early/pseudo TAs. Is there a
plan for OpteeLib to support loading full TAs?
- We have two client drivers: a firmware TPM TA driver and an authenticated
variable TA driver. These talk through the tee-supplicant to their respective
TAs.
Chris
> -Original Message-
> From: Sumit Garg
> Sent: Thursday, November 1, 2018 3:55 AM
> To: Chris Co ; Leif Lindholm
>
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel ;
> Michael D Kinney
> Subject: Re: [PATCH edk2-platforms 01/27] Platform/Microsoft: Add
> OpteeClientPkg dec
>
> Hi Christopher,
>
> Optee Client library has recently been merged to edk2 source code. It tries to
> provide a generic interface [1] to OP-TEE based trusted applications
> (pseudo/early).
>
> AFAIK, you don't need any platform specific hook in client interface to work
> with upstream OP-TEE. So instead you should use Optee library.
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FInclude%2FLibrary
> %2FOpteeLib.hdata=02%7C01%7CChristopher.Co%40microsoft.com%7C
> c19b84ef7f8f4213424108d63fe88f66%7C72f988bf86f141af91ab2d7cd011db47
> %7C1%7C0%7C63675404786500sdata=m24akbKtoyCERVN77meoSU
> H6E%2Bpf8W2P5MF7nvU5y7I%3Dreserved=0
>
> Regards,
> Sumit
>
> On Thu, 1 Nov 2018 at 02:13, Leif Lindholm wrote:
> >
> > +Sumit (just to loop you two together). Is there anything Microsoft
> > platform specific about what will go in here?
> >
> > /
> > Leif
> >
> > On Fri, Sep 21, 2018 at 08:25:53AM +, Chris Co wrote:
> > > On Windows IoT Core devices with ARM TrustZone capabilities,
> > > EDK2 runs in normal world and we use OP-TEE to execute secure world
> > > operations. The overall package will contain client-side support to
> > > invoke EDK2 services implemented as OP-TEE trusted applications that
> > > run in secure world.
> > >
> > > This commit adds the initial dec file to add some PCD settings
> > > needed by other packages.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Christopher Co
> > > Cc: Ard Biesheuvel
> > > Cc: Leif Lindholm
> > > Cc: Michael D Kinney
> > > ---
> > > Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec | 49
> > >
> > > 1 file changed, 49 insertions(+)
> > >
> > > diff --git a/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > > b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > > new file mode 100644
> > > index ..4752eab39ce3
> > > --- /dev/null
> > > +++ b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > > @@ -0,0 +1,49 @@
> > > +## @file
> > > +#
> > > +# OP-TEE client package
> > > +#
> > > +# OP-TEE client package contains the client-side interface to invoke OP-
> TEE TAs.
> > > +# Certain EDKII services are implemented in Trusted Applications
> > > +running in # the secure world OP-TEE OS.
> > > +#
> > > +# Copyright (c) 2018 Microsoft Corporation. All rights reserved.
> > > +#
> > > +# This program and the accompanying materials # are licensed and
> > > +made available under the terms and conditions of the BSD License #
> > > +which accompanies this distribution. The full text of the license
> > > +may be found at #
> > > +https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> > > +nsource.org%2Flicenses%2Fbsd-
> license.phpdata=02%7C01%7CChristo
> > >
> +pher.Co%40microsoft.com%7Cc19b84ef7f8f4213424108d63fe88f66%7C72f988
> > >
> +bf86f141af91ab2d7cd011db47%7C1%7C0%7C63675404786500sda
> ta=1
> > > +MxFvlsMPhk19grEexBXo5VqRd0jZaCSRjxZCi87A2w%3Dreserved=0
> > > +#
> > > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > > +BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > > +#
> > > +##
> > > +
> > > +[Defines]
> > > + DEC_SPECIFICATION = 0x0001001A
> > > + PACKAGE_NAME = OpteeClientPkg
> > > + PACKAGE_GUID = 77416fcb-10ec-4693-bdc0-1bdd74ec9595
> > > + PACKAGE_VERSION= 0.01
> > > +
> > > +[Includes]
> > > +
> > > +[LibraryClasses]
> > > +
> > > +[Guids]
> > > + gOpteeClientPkgTokenSpaceGuid = { 0x04ad34ca, 0xdd25, 0x4156, {
> 0x90, 0xf5, 0x16, 0xf9, 0x40, 0xd0, 0x49, 0xe3 }}
> > > +
> > > +[PcdsFixedAtBuild]
> > > +
> > >
> +gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferBase|0|UINT64|0x
> > > +0005
> > > +
> > >
> +gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferSize|0|UINT32|0x
> > > +0006
> > > +
> > > + ## The base address of the Trust Zone OpTEE OS private memory
> > > + region # This memory is manager
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
Hi Christopher,
Optee Client library has recently been merged to edk2 source code. It
tries to provide a generic interface [1] to OP-TEE based trusted
applications (pseudo/early).
AFAIK, you don't need any platform specific hook in client interface
to work with upstream OP-TEE. So instead you should use Optee library.
[1]
https://github.com/tianocore/edk2/blob/master/ArmPkg/Include/Library/OpteeLib.h
Regards,
Sumit
On Thu, 1 Nov 2018 at 02:13, Leif Lindholm wrote:
>
> +Sumit (just to loop you two together). Is there anything Microsoft
> platform specific about what will go in here?
>
> /
> Leif
>
> On Fri, Sep 21, 2018 at 08:25:53AM +, Chris Co wrote:
> > On Windows IoT Core devices with ARM TrustZone capabilities,
> > EDK2 runs in normal world and we use OP-TEE to execute
> > secure world operations. The overall package will contain
> > client-side support to invoke EDK2 services implemented as
> > OP-TEE trusted applications that run in secure world.
> >
> > This commit adds the initial dec file to add some PCD settings
> > needed by other packages.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Christopher Co
> > Cc: Ard Biesheuvel
> > Cc: Leif Lindholm
> > Cc: Michael D Kinney
> > ---
> > Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec | 49
> >
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > new file mode 100644
> > index ..4752eab39ce3
> > --- /dev/null
> > +++ b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> > @@ -0,0 +1,49 @@
> > +## @file
> > +#
> > +# OP-TEE client package
> > +#
> > +# OP-TEE client package contains the client-side interface to invoke
> > OP-TEE TAs.
> > +# Certain EDKII services are implemented in Trusted Applications running
> > in
> > +# the secure world OP-TEE OS.
> > +#
> > +# Copyright (c) 2018 Microsoft Corporation. All rights reserved.
> > +#
> > +# This program and the accompanying materials
> > +# are licensed and made available under the terms and conditions of the
> > BSD License
> > +# which accompanies this distribution. The full text of the license may
> > be found at
> > +# http://opensource.org/licenses/bsd-license.php
> > +#
> > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> > IMPLIED.
> > +#
> > +##
> > +
> > +[Defines]
> > + DEC_SPECIFICATION = 0x0001001A
> > + PACKAGE_NAME = OpteeClientPkg
> > + PACKAGE_GUID = 77416fcb-10ec-4693-bdc0-1bdd74ec9595
> > + PACKAGE_VERSION= 0.01
> > +
> > +[Includes]
> > +
> > +[LibraryClasses]
> > +
> > +[Guids]
> > + gOpteeClientPkgTokenSpaceGuid = { 0x04ad34ca, 0xdd25, 0x4156, { 0x90,
> > 0xf5, 0x16, 0xf9, 0x40, 0xd0, 0x49, 0xe3 }}
> > +
> > +[PcdsFixedAtBuild]
> > + gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferBase|0|UINT64|0x0005
> > + gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferSize|0|UINT32|0x0006
> > +
> > + ## The base address of the Trust Zone OpTEE OS private memory region
> > + # This memory is manager privately by the OpTEE OS.
> > +
> > gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemoryBase|0xDEAD1|UINT64|0x0001
> > +
> > + ## The size of the Trust Zone OpTEE OS private memory region
> > +
> > gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemorySize|55|UINT64|0x0002
> > +
> > + ## The base address of the Trust Zone OpTEE OS shared memory region
> > +
> > gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemoryBase|0xDEAD2|UINT64|0x0003
> > +
> > + ## The size of the Trust Zone OpTEE OS shared memory region
> > +
> > gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemorySize|0xAA|UINT64|0x0004
> > --
> > 2.16.2.gvfs.1.33.gf5370f1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
+Sumit (just to loop you two together). Is there anything Microsoft
platform specific about what will go in here?
/
Leif
On Fri, Sep 21, 2018 at 08:25:53AM +, Chris Co wrote:
> On Windows IoT Core devices with ARM TrustZone capabilities,
> EDK2 runs in normal world and we use OP-TEE to execute
> secure world operations. The overall package will contain
> client-side support to invoke EDK2 services implemented as
> OP-TEE trusted applications that run in secure world.
>
> This commit adds the initial dec file to add some PCD settings
> needed by other packages.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Christopher Co
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> ---
> Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec | 49
>
> 1 file changed, 49 insertions(+)
>
> diff --git a/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> new file mode 100644
> index ..4752eab39ce3
> --- /dev/null
> +++ b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
> @@ -0,0 +1,49 @@
> +## @file
> +#
> +# OP-TEE client package
> +#
> +# OP-TEE client package contains the client-side interface to invoke OP-TEE
> TAs.
> +# Certain EDKII services are implemented in Trusted Applications running in
> +# the secure world OP-TEE OS.
> +#
> +# Copyright (c) 2018 Microsoft Corporation. All rights reserved.
> +#
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be
> found at
> +# http://opensource.org/licenses/bsd-license.php
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +#
> +##
> +
> +[Defines]
> + DEC_SPECIFICATION = 0x0001001A
> + PACKAGE_NAME = OpteeClientPkg
> + PACKAGE_GUID = 77416fcb-10ec-4693-bdc0-1bdd74ec9595
> + PACKAGE_VERSION= 0.01
> +
> +[Includes]
> +
> +[LibraryClasses]
> +
> +[Guids]
> + gOpteeClientPkgTokenSpaceGuid = { 0x04ad34ca, 0xdd25, 0x4156, { 0x90,
> 0xf5, 0x16, 0xf9, 0x40, 0xd0, 0x49, 0xe3 }}
> +
> +[PcdsFixedAtBuild]
> + gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferBase|0|UINT64|0x0005
> + gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferSize|0|UINT32|0x0006
> +
> + ## The base address of the Trust Zone OpTEE OS private memory region
> + # This memory is manager privately by the OpTEE OS.
> +
> gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemoryBase|0xDEAD1|UINT64|0x0001
> +
> + ## The size of the Trust Zone OpTEE OS private memory region
> +
> gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemorySize|55|UINT64|0x0002
> +
> + ## The base address of the Trust Zone OpTEE OS shared memory region
> +
> gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemoryBase|0xDEAD2|UINT64|0x0003
> +
> + ## The size of the Trust Zone OpTEE OS shared memory region
> +
> gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemorySize|0xAA|UINT64|0x0004
> --
> 2.16.2.gvfs.1.33.gf5370f1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec
On Windows IoT Core devices with ARM TrustZone capabilities,
EDK2 runs in normal world and we use OP-TEE to execute
secure world operations. The overall package will contain
client-side support to invoke EDK2 services implemented as
OP-TEE trusted applications that run in secure world.
This commit adds the initial dec file to add some PCD settings
needed by other packages.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher Co
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Michael D Kinney
---
Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec | 49
1 file changed, 49 insertions(+)
diff --git a/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
new file mode 100644
index ..4752eab39ce3
--- /dev/null
+++ b/Platform/Microsoft/OpteeClientPkg/OpteeClientPkg.dec
@@ -0,0 +1,49 @@
+## @file
+#
+# OP-TEE client package
+#
+# OP-TEE client package contains the client-side interface to invoke OP-TEE
TAs.
+# Certain EDKII services are implemented in Trusted Applications running in
+# the secure world OP-TEE OS.
+#
+# Copyright (c) 2018 Microsoft Corporation. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+##
+
+[Defines]
+ DEC_SPECIFICATION = 0x0001001A
+ PACKAGE_NAME = OpteeClientPkg
+ PACKAGE_GUID = 77416fcb-10ec-4693-bdc0-1bdd74ec9595
+ PACKAGE_VERSION= 0.01
+
+[Includes]
+
+[LibraryClasses]
+
+[Guids]
+ gOpteeClientPkgTokenSpaceGuid = { 0x04ad34ca, 0xdd25, 0x4156, { 0x90,
0xf5, 0x16, 0xf9, 0x40, 0xd0, 0x49, 0xe3 }}
+
+[PcdsFixedAtBuild]
+ gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferBase|0|UINT64|0x0005
+ gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferSize|0|UINT32|0x0006
+
+ ## The base address of the Trust Zone OpTEE OS private memory region
+ # This memory is manager privately by the OpTEE OS.
+
gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemoryBase|0xDEAD1|UINT64|0x0001
+
+ ## The size of the Trust Zone OpTEE OS private memory region
+
gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemorySize|55|UINT64|0x0002
+
+ ## The base address of the Trust Zone OpTEE OS shared memory region
+
gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemoryBase|0xDEAD2|UINT64|0x0003
+
+ ## The size of the Trust Zone OpTEE OS shared memory region
+
gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemorySize|0xAA|UINT64|0x0004
--
2.16.2.gvfs.1.33.gf5370f1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
