+ 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: 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... [2] https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/OpteeLib/Optee....
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%2Fgithub.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%2Fope +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|UIN
- 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
Hi Sumit,
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Thursday, November 1, 2018 10:24 PM To: Chris Co Christopher.Co@microsoft.com Cc: Leif Lindholm leif.lindholm@linaro.org; edk2-devel@lists.01.org; Ard Biesheuvel ard.biesheuvel@linaro.org; Michael D Kinney michael.d.kinney@intel.com; tee-dev@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 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.
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- 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%2Fgithub.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%2Fgit 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|UIN
- 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
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 Sent: Thursday, November 1, 2018 10:24 PM To: Chris Co Christopher.Co@microsoft.com Cc: Leif Lindholm leif.lindholm@linaro.org; edk2-devel@lists.01.org; Ard Biesheuvel ard.biesheuvel@linaro.org; Michael D Kinney michael.d.kinney@intel.com; tee-dev@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 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?
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- 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%2Fgithub.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%2Fgit 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|UIN
- 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
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 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-...
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_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 >
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 > >
-
Chris Co -
Sumit Garg