Hi Chris,
On Tue, 6 Nov 2018 at 07:23, Chris Co Christopher.Co@microsoft.com wrote:
Hi Sumit,
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org
Hi Chris,
On Sat, 3 Nov 2018 at 05:25, Chris Co Christopher.Co@microsoft.com wrote:
Hi Sumit,
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org
- OP-TEE ML.
On Fri, 2 Nov 2018 at 06:11, Chris Co Christopher.Co@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:
- Increased boot time.
- 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-...
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 - OPTEE_MSG_RPC_CMD_LOAD_TA
Please see above comments for this.
- OPTEE_MSG_RPC_CMD_RPMB - OPTEE_MSG_RPC_CMD_GET_TIMECan 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_QUEUEI 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.garg@linaro.org Sent: Thursday, November 1, 2018 3:55 AM To: Chris Co Christopher.Co@microsoft.com; Leif Lindholm leif.lindholm@linaro.org Cc: edk2-devel@lists.01.org; Ard Biesheuvel ard.biesheuvel@linaro.org; Michael D Kinney michael.d.kinney@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.lindholm@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.co@microsoft.com > > Cc: Ard Biesheuvel ard.biesheuvel@linaro.org > > Cc: Leif Lindholm leif.lindholm@linaro.org > > Cc: Michael D Kinney michael.d.kinney@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 > >