[RFC] add support for secure partition (SPM-like) #3973

apalos · 2020-07-15T20:38:07Z

Secure variable storage for EFI variables is critical for enabling and
protecting UEFI Secure Boot. Unfortunately due to the fact that SPD and
SPM are mutually exclusive, we can't run StMM from EDK2 and OP-TEE.
An advantage of doing so is that different firmware implementations
can leverage EDK2's StandAloneMM and in cooperation with OP-TEE RPMB
APIs can store UEFI variables in a secure storage.
This makes the variable storage quite generic in any device with an RPMB
partition.

Using a well debugged application is preferable over rewriting the whole
application as a TA. Another advantage is that this inherits the Fault
Tolerant Writes (FTW) functionality built-in on StMM to protect
variables against corruptions during writing. Considering the FFA
changes of the future Arm architectures using an SP that includes
everything seems like a better choice at the moment.
The 'SPM emulation' currently added into OP-TEE only supports
a single SP to be launched. This means that the StMM embedded
application has the RPMB driver built in at the moment. In the future we
can add code (evolving FFA) to launch multiple SPs. So the StMM variable
handling can be decoupled from the RPMB driver, which will reside in a
different SP.

So let's add a user mode secure partition context and support loading
"Standalone MM" of EDK2 into it. A separate syscall handling is added to
serve as different kind of ABI and syscall IDs. The secure partition has
a TA like interface towards normal world, but requests are routed into
the StMM partition instead.

CFG_STMM_PATH is assigned the path of BL32_AP_MM.fd, for instance:
CFG_STMM_PATH=...Build/QemuVirtMmStandalone/DEBUG_GCC5/FV/BL32_AP_MM.fd

Since this is quite tricky to compile and test you can use this [1].
Just clone the repo and run ./build.sh. The script will pick up edk2,
edk2-platforms, op-tee, atf and U-boot and compile all the necessary
binaries for QEMU. A patch (awful hack) has been added to U-boot to
allow RPMB emulation through it's supplicant, since QEMU RPMB emulation
is not yet available.
After compiling and launching QEMU the usual U-boot commands for EFI
variable management will store the variables on an RPMB device.

[1] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/

Changes Since RFC:

Addressed @jenswi-linaro comments
Moved I/EMSG to DMSG
Removed pointless register restoring
Restoring x0-x7 in return_helper() (needed for FFA)
cherry picked FFA changes, so those are not included in the current patchset
Using mobj_inc_map() to map memory instead of the custom function
Added sp_svc_get_mem_attr() to get a page attributes properly (instead of assuming RWX we did in the RFC).
Also added vm_get_attrs() helper function.
Removed the weird masking flags used in sp_svc_set_mem_attr(). This was a result of using hardcoded (RWX flags for reading the current pages attributes)
Moved comment to /* .... */ format
Used return_helper() when appropriate, instead of manually defining the error flags
Masked x3-x7, with 0xffffffff when used for FFA

Changes since v1:

renamed vm_get_attrs() -> vm_get_prot() and masked the output. This was also placed on a separate commit.
Don't mask x3-x7 with 0xffffffff as it's not needed
Initialized all stack variables
removed stale thread_[g|s]et_cntkctl_el1 functions
Fixed a bug on unti16_t shifting
Added a shippable build target
removed reduntant checks before reading/writing a file

core/arch/arm/include/ffa.h

core/arch/arm/kernel/secure_partition.c

core/arch/arm/include/kernel/secure_partition.h

core/arch/arm/kernel/secure_partition.c

core/arch/arm/kernel/thread_a64.S

core/arch/arm/kernel/thread_private.h

core/arch/arm/mm/tee_mmu.c

jenswi-linaro · 2020-07-21T10:26:05Z

We should probably have Shippable target for StMM in .shippable.yml to make sure that the code always compiles.
It should be OK to piggyback on the first PLATFORM=vexpress-qemu_armv8a target.

apalos · 2020-07-21T13:22:36Z

We should probably have Shippable target for StMM in .shippable.yml to make sure that the code always compiles.
It should be OK to piggyback on the first PLATFORM=vexpress-qemu_armv8a target.

Sure. What about the included binary? As you know the EDK2 code is not merged yet, so any suggestions for CFG_STMM_PATH? Touch a dummy file and use that?

jenswi-linaro · 2020-07-21T13:35:12Z

Yeah, creating a dummy file on the fly should be OK. You could try to make that file the typical size of the StMM binary so we catch eventual overflows in the binary.

core/arch/arm/kernel/secure_partition.c

core/arch/arm/include/pta_stmm.h

core/arch/arm/kernel/secure_partition.c

core/include/mm/tee_mmu.h

.shippable.yml

core/arch/arm/mm/tee_mmu.c

core/arch/arm/include/kernel/secure_partition.h

jenswi-linaro · 2020-07-23T14:18:09Z

Please fix the shippable error.

jenswi-linaro · 2020-07-23T15:23:03Z

Feel free to squash and fixup the commits. Should hopefully take care the travis errors, except the ones about extern which we'll have to accept.

jenswi-linaro · 2020-08-10T08:26:41Z

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Please rebase while applying the tag.

core/arch/arm/kernel/secure_partition.c

jenswi-linaro · 2020-08-14T08:56:25Z

Looks good, please squash and rebase.

core/arch/arm/include/kernel/secure_partition.h

core/arch/arm/kernel/secure_partition.c

core/arch/arm/include/kernel/secure_partition.h

core/arch/arm/kernel/secure_partition.c

jenswi-linaro · 2020-08-20T09:02:20Z

Looks good

etienne-lms

Acked-by: Etienne Carriere <etienne.carriere@linaro.org> with the 2 "coding style to address:" comments addressed. Other comments are free to consider or not...

core/include/kernel/user_mode_ctx.h

core/arch/arm/kernel/secure_partition.c

jenswi-linaro · 2020-08-27T07:03:41Z

For commit "shippable: build secure partition code":
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

If all comments are addressed perhaps you can fix up the commits and we should be good to merge.

.shippable.yml

jforissier · 2020-08-31T12:55:14Z

For "shippable: build secure partition code":

Acked-by: Jerome Forissier <jerome@forissier.org>

apalos · 2020-09-07T05:55:38Z

@jforissier anything missing to merge this?

jforissier · 2020-09-07T06:27:37Z

@apalos yes, the Acked-by tags, please.

apalos · 2020-09-07T06:32:39Z

@apalos yes, the Acked-by tags, please.

@jforissier fixed!

jforissier · 2020-09-07T06:44:40Z

Etienne's ack is missing on the first and last commits, I think they are applicable (the commits existed when he posted them, and the commits did not evolve substentialy afterwards).

apalos · 2020-09-07T06:51:37Z

Etienne's ack is missing on the first and last commits, I think they are applicable (the commits existed when he posted them, and the commits did not evolve substentialy afterwards).

He only commented on commit patch no. 2, I can add his acked-by tag on the rest if that was what he meant

jforissier · 2020-09-07T06:58:14Z

When someone gives an ack without citing specific commits, it means all of them.

A following commit, related to the StMM functionality needs to read the current page attributes before modifying them. So let's add a function to retrieve the current attributes. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

Secure variable storage for EFI variables is critical for enabling and protecting UEFI Secure Boot. Unfortunately due to the fact that SPD and SPM are mutually exclusive, we can't run StMM from EDK2 and OP-TEE. An advantage of doing so is that different firmware implementations can leverage EDK2's StandAloneMM and in cooperation with OP-TEE RPMB APIs can store UEFI variables in a secure storage. This makes the variable storage quite generic in any device with an RPMB partition. Using a well debugged application is preferable over rewriting the whole application as a TA. Another advantage is that this inherits the Fault Tolerant Writes (FTW) functionality built-in on StMM to protect variables against corruptions during writing. Considering the FFA changes of the future Arm architectures using an SP that includes everything seems like a better choice at the moment. The 'SPM emulation' currently added into OP-TEE only supports a single SP to be launched. This means that the StMM embedded application has the RPMB driver built in at the moment. In the future we can add code (evolving FFA) to launch multiple SPs. So the StMM variable handling can be decoupled from the RPMB driver, which will reside in a different SP. So let's add a user mode secure partition context and support loading "Standalone MM" of EDK2 into it. A separate syscall handling is added to serve as different kind of ABI and syscall IDs. The secure partition has a TA like interface towards normal world, but requests are routed into the StMM partition instead. CFG_STMM_PATH is assigned the path of BL32_AP_MM.fd, for instance: CFG_STMM_PATH=...Build/QemuVirtMmStandalone/DEBUG_GCC5/FV/BL32_AP_MM.fd Since this is quite tricky to compile and test you can use this [1]. Just clone the repo and run ./build.sh. The script will pick up edk2, edk2-platforms, op-tee, atf and U-boot and compile all the necessary binaries for QEMU. A patch (awful hack) has been added to U-boot to allow RPMB emulation through it's supplicant, since QEMU RPMB emulation is not yet available. After compiling and launching QEMU the usual U-boot commands for EFI variable management will store the variables on an RPMB device. [1] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/ Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Co-developed-by: Pipat Methavanitpong <pipat1010@gmail.com> Signed-off-by: Pipat Methavanitpong <pipat1010@gmail.com> Co-developed-by: Miklos Balint <Miklos.Balint@arm.com> Signed-off-by: Miklos Balint <Miklos.Balint@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

A previous commit adds support for secure partition loading, acting similarly to SPM in order to launch StandAloneMM. Let's add this to shippable and make sure the new code at least compiles properly. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Jerome Forissier <jerome@forissier.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

apalos · 2020-09-07T07:04:21Z

No problem, added the missing ACKs

jforissier · 2020-09-07T08:01:56Z

Thanks @apalos.

With some recent changes in OP-TEE [1] and U-Boot [2] we can compile StMM and launch it from an OP-TEE secure partition which is mimicking SPM. There's a number of advantages in this approach. In Arm world SPM, currently used for dispatching StMM, and SPD used for OP-TEE, are mutually exclusive. Since there's no application in OP-TEE for managing EFI variables, this means that one can have a secure OS or secure variable storage. By re-using StMM we have EDK2s approved application controlling variable storage and the ability to run a secure world OS. This also allows various firmware implementations to adopt EDK2 way of storing variables (including the FTW implementation), as long as OP-TEE is available on that given platform (or any other secure OS that can launch StMM and has a supplicant for handling the RPMB partition). Another advantage is that OP-TEE has the ability to access an eMMC RPMB partition to store those variables. This requires a normal world supplicant, which is implemented in U-Boot currently. The supplicant picks up the encrypted buffer from OP-TEE and wires it to the eMMC driver(s). Similar functionality can be added in EDK2 by porting the supplicant and adapt it to using the native eMMC drivers. There's is one drawback in using OP-TEE. The current SPM calls need to run to completion. This contradicts the current OP-TEE RPC call requirements, used to access the RPMB storage. Thats leads to two different SMC calls for entering secure world to access StMM. So let's add support for a platform that compiles StMM and an RPMB driver that communicates with OP-TEE to read/write the variables. For anyone interested in testing this there's repo that builds all the sources and works on QEMU [3]. [1] OP-TEE/optee_os#3973 [2] http://u-boot.10912.n7.nabble.com/PATCH-0-7-v4-EFI-variable-support-via-OP-TEE-td412499.html [3] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/ Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

With some recent changes in OP-TEE [1] and U-Boot [2] we can compile StMM and launch it from an OP-TEE secure partition which is mimicking SPM. There's a number of advantages in this approach. In Arm world SPM, currently used for dispatching StMM, and SPD used for OP-TEE, are mutually exclusive. Since there's no application in OP-TEE for managing EFI variables, this means that one can have a secure OS or secure variable storage. By re-using StMM we have EDK2s approved application controlling variable storage and the ability to run a secure world OS. This also allows various firmware implementations to adopt EDK2 way of storing variables (including the FTW implementation), as long as OP-TEE is available on that given platform (or any other secure OS that can launch StMM and has a supplicant for handling the RPMB partition). Another advantage is that OP-TEE has the ability to access an eMMC RPMB partition to store those variables. This requires a normal world supplicant, which is implemented in U-Boot currently. The supplicant picks up the encrypted buffer from OP-TEE and wires it to the eMMC driver(s). Similar functionality can be added in EDK2 by porting the supplicant and adapt it to using the native eMMC drivers. There's is one drawback in using OP-TEE. The current SPM calls need to run to completion. This contradicts the current OP-TEE RPC call requirements, used to access the RPMB storage. Thats leads to two different SMC calls for entering secure world to access StMM. So let's add support for a platform that compiles StMM and an RPMB driver that communicates with OP-TEE to read/write the variables. For anyone interested in testing this there's repo that builds all the sources and works on QEMU [3]. [1] OP-TEE/optee_os#3973 [2] http://u-boot.10912.n7.nabble.com/PATCH-0-7-v4-EFI-variable-support-via-OP-TEE-td412499.html [3] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/ Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

jenswi-linaro reviewed Jul 16, 2020

View reviewed changes

apalos force-pushed the stmm_pr branch from e16252a to 72f7a0f Compare July 20, 2020 12:05

jenswi-linaro reviewed Jul 21, 2020

View reviewed changes

apalos force-pushed the stmm_pr branch 2 times, most recently from a378585 to 5056a23 Compare July 21, 2020 20:31

jenswi-linaro reviewed Jul 22, 2020

View reviewed changes

core/arch/arm/mm/tee_mmu.c Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from 1957719 to 498e49f Compare July 23, 2020 08:36

jenswi-linaro reviewed Jul 23, 2020

View reviewed changes

core/arch/arm/mm/tee_mmu.c Outdated Show resolved Hide resolved

core/arch/arm/include/kernel/secure_partition.h Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from a324f17 to ab21c52 Compare July 23, 2020 15:59

apalos commented Aug 12, 2020

View reviewed changes

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

jenswi-linaro reviewed Aug 13, 2020

View reviewed changes

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from 1d913a0 to a3bca27 Compare August 14, 2020 09:02

jenswi-linaro reviewed Aug 14, 2020

View reviewed changes

core/arch/arm/include/kernel/secure_partition.h Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from 8325e95 to c618387 Compare August 17, 2020 13:50

jenswi-linaro reviewed Aug 17, 2020

View reviewed changes

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

jenswi-linaro reviewed Aug 18, 2020

View reviewed changes

core/arch/arm/kernel/secure_partition.c Show resolved Hide resolved

etienne-lms reviewed Aug 18, 2020

View reviewed changes

etienne-lms reviewed Aug 19, 2020

View reviewed changes

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

core/arch/arm/kernel/secure_partition.c Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from 3482a99 to 9ffae63 Compare August 20, 2020 05:53

apalos force-pushed the stmm_pr branch from 9ffae63 to 88994d6 Compare August 20, 2020 09:28

etienne-lms reviewed Aug 20, 2020

View reviewed changes

jforissier reviewed Aug 27, 2020

View reviewed changes

.shippable.yml Outdated Show resolved Hide resolved

apalos force-pushed the stmm_pr branch from 7410039 to 83eb909 Compare August 31, 2020 12:49

apalos force-pushed the stmm_pr branch from 83eb909 to 21acc12 Compare September 7, 2020 06:32

apalos and others added 3 commits September 7, 2020 10:03

apalos force-pushed the stmm_pr branch from 21acc12 to e8e990d Compare September 7, 2020 07:04

jforissier merged commit 493c208 into OP-TEE:master Sep 7, 2020

super119 mentioned this pull request Jul 6, 2021

OP-TEE 3.13: Is CFG_STMM_PATH still working? #4726

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RFC] add support for secure partition (SPM-like) #3973

[RFC] add support for secure partition (SPM-like) #3973

apalos commented Jul 15, 2020 •

edited

Loading

jenswi-linaro commented Jul 21, 2020 •

edited

Loading

apalos commented Jul 21, 2020

jenswi-linaro commented Jul 21, 2020

jenswi-linaro commented Jul 23, 2020

jenswi-linaro commented Jul 23, 2020

jenswi-linaro commented Aug 10, 2020

jenswi-linaro commented Aug 14, 2020

jenswi-linaro commented Aug 20, 2020

etienne-lms left a comment

jenswi-linaro commented Aug 27, 2020

jforissier commented Aug 31, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020 •

edited

Loading

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

[RFC] add support for secure partition (SPM-like) #3973

[RFC] add support for secure partition (SPM-like) #3973

Conversation

apalos commented Jul 15, 2020 • edited Loading

jenswi-linaro commented Jul 21, 2020 • edited Loading

apalos commented Jul 21, 2020

jenswi-linaro commented Jul 21, 2020

jenswi-linaro commented Jul 23, 2020

jenswi-linaro commented Jul 23, 2020

jenswi-linaro commented Aug 10, 2020

jenswi-linaro commented Aug 14, 2020

jenswi-linaro commented Aug 20, 2020

etienne-lms left a comment

Choose a reason for hiding this comment

jenswi-linaro commented Aug 27, 2020

jforissier commented Aug 31, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020 • edited Loading

jforissier commented Sep 7, 2020

apalos commented Sep 7, 2020

jforissier commented Sep 7, 2020

apalos commented Jul 15, 2020 •

edited

Loading

jenswi-linaro commented Jul 21, 2020 •

edited

Loading

apalos commented Sep 7, 2020 •

edited

Loading