Hi Sumit, > -----Original Message----- > From: Sumit Garg <sumit.g...@linaro.org> > > Hi Chris, > > On Sat, 3 Nov 2018 at 05:25, Chris Co <christopher...@microsoft.com> wrote: > > > > Hi Sumit, > > > > > -----Original Message----- > > > From: Sumit Garg <sumit.g...@linaro.org> > > > > > > + OP-TEE ML. > > > > > > On Fri, 2 Nov 2018 at 06:11, Chris Co <christopher...@microsoft.com> > 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 execution flow on boot core. > Agreed. Our implementation is effectively a no-op. We don't need this either. > 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. > I'll see if I can find time to port over our RPC handlers. Will add you to any patches for review. Thanks, Chris > Regards, > Sumit > > > > > Thanks, > > Chris > > > > > [1] > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.c > > > om%2FOP- > > > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fdocumentation%2Foptee_design.md > > > %23early-trusted- > > > > applications&data=02%7C01%7CChristopher.Co%40microsoft.com%7C4a > > > > 7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd011db47% > > > > 7C1%7C0%7C636767330779998429&sdata=yaDWw5Z6yuux1o89kxzbknVp > > > b%2B1OHUagbB%2FOGS4dAcU%3D&reserved=0 > > > [2] > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.c > > > > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FLibrary%2FOpteeL > > > > ib%2FOptee.c%23L147&data=02%7C01%7CChristopher.Co%40microsoft.c > > > > om%7C4a7d8c01e4804365f4eb08d640837a15%7C72f988bf86f141af91ab2d7cd > > > > 011db47%7C1%7C0%7C636767330779998429&sdata=Lsplb1L7Ugd2C6cXG > > > 8gBo40Ei8UQPtIA7fNEDL1t%2Fbg%3D&reserved=0 > > > > > > Regards, > > > Sumit > > > > > > > Chris > > > > > > > > > -----Original Message----- > > > > > From: Sumit Garg <sumit.g...@linaro.org> > > > > > Sent: Thursday, November 1, 2018 3:55 AM > > > > > To: Chris Co <christopher...@microsoft.com>; Leif Lindholm > > > > > <leif.lindh...@linaro.org> > > > > > Cc: edk2-devel@lists.01.org; Ard Biesheuvel > > > > > <ard.biesheu...@linaro.org>; Michael D Kinney > > > > > <michael.d.kin...@intel.com> > > > > > 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%2 > > > > > Fgit > > > > > hub.c > > > > > > > > > om%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FArmPkg%2FInclude%2FLibrary > > > > > > > > > %2FOpteeLib.h&data=02%7C01%7CChristopher.Co%40microsoft.com%7C > > > > > > > > > c19b84ef7f8f4213424108d63fe88f66%7C72f988bf86f141af91ab2d7cd011db47 > > > > > > > > > %7C1%7C0%7C636766665404786500&sdata=m24akbKtoyCERVN77meoSU > > > > > H6E%2Bpf8W2P5MF7nvU5y7I%3D&reserved=0 > > > > > > > > > > Regards, > > > > > Sumit > > > > > > > > > > On Thu, 1 Nov 2018 at 02:13, Leif Lindholm > > > > > <leif.lindh...@linaro.org> > > > 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 +0000, 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 <christopher...@microsoft.com> > > > > > > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > > > > > > > Cc: Leif Lindholm <leif.lindh...@linaro.org> > > > > > > > Cc: Michael D Kinney <michael.d.kin...@intel.com> > > > > > > > --- > > > > > > > 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 000000000000..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%2 > > > > > > > +Fope > > > > > > > +nsource.org%2Flicenses%2Fbsd- > > > > > license.php&data=02%7C01%7CChristo > > > > > > > > > > > > > > > > +pher.Co%40microsoft.com%7Cc19b84ef7f8f4213424108d63fe88f66%7C72f988 > > > > > > > > > > > > > > > > +bf86f141af91ab2d7cd011db47%7C1%7C0%7C636766665404786500&sda > > > > > ta=1 > > > > > > > > > > +MxFvlsMPhk19grEexBXo5VqRd0jZaCSRjxZCi87A2w%3D&reserved=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|0x0000 > > > > > > > +0005 > > > > > > > + > > > > > > > > > > > > > > > > +gOpteeClientPkgTokenSpaceGuid.PcdTpm2AcpiBufferSize|0|UINT32|0x0000 > > > > > > > +0006 > > > > > > > + > > > > > > > + ## The base address of the Trust Zone OpTEE OS private > > > > > > > + memory region # This memory is manager privately by the OpTEE > OS. > > > > > > > + > > > > > > > + > > > > > > > > > gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemoryBase|0xDEAD > > > > > > > + 1|UINT64|0x00000001 > > > > > > > + > > > > > > > + ## The size of the Trust Zone OpTEE OS private memory > > > > > > > + region > > > > > > > + > > > > > > > + > > > > > > gOpteeClientPkgTokenSpaceGuid.PcdTrustZonePrivateMemorySize|55|U > > > > > IN > > > > > > > + T64|0x00000002 > > > > > > > + > > > > > > > + ## The base address of the Trust Zone OpTEE OS shared > > > > > > > + memory region > > > > > > > + > > > > > > > + > > > > > > > > > gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemoryBase|0xDEAD2 > > > > > > > + |UINT64|0x00000003 > > > > > > > + > > > > > > > + ## The size of the Trust Zone OpTEE OS shared memory > > > > > > > + region > > > > > > > + > > > > > > > + > > > > > > > > > gOpteeClientPkgTokenSpaceGuid.PcdTrustZoneSharedMemorySize|0xAA|UI > > > > > > > + NT64|0x00000004 > > > > > > > -- > > > > > > > 2.16.2.gvfs.1.33.gf5370f1 > > > > > > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
