SPM (responsible for dispatching StMM) and SPD (for OP-TEE) are mutually
exclusive and there's no Trusted Application in OP-TEE for managing
EFI variables (only a Microsoft one, for Authenticated variables).
This means that one can have a secure OS or secure variable storage.
With some recent changes merged in OP-TEE [1] and U-Boot [2] we can
launch StMM from an OP-TEE secure partition which is mimicking SPM.
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, so any platform with OP-TEE and an
eMMC can store variables securely.
This requires a normal world supplicant, which is implemented in U-Boot
currently. Similar functionality can be added in EDK2 by porting the
supplicant and adapt it to using the native eMMC drivers.
Although this approach might seem counter-intuitive at first glance,
considering the FFA [3] in Arm architecture, using a Secure Partition that
includes everything seems like a better choice at the moment and is
preferred over a rewritten from scratch TA.
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 (one for SPM and one for SPD).
Since this is quite tricky to compile and test you can use this [4].
Just clone the repo and run ./build.sh. The script will pick up edk2,
edk2-platforms, op-tee, TF-A and U-boot and compile all the necessary
binaries for QEMU. A patch (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 the emulated RPMB device.
[1] https://github.com/OP-TEE/optee_os/pull/3973
[2] http://u-boot.10912.n7.nabble.com/PATCH-0-7-v4-EFI-variable-support-via-OP-TEE-td412499.html
[3] https://developer.arm.com/documentation/den0077/a
[4] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/
Ilias Apalodimas (2):
Drivers/OpTeeRpmb: Add an OP-TEE backed RPMB driver
StMMRpmb: Add support for building StandaloneMm image for OP-TEE
Platform/StMMRpmb/PlatformStandaloneMm.dsc | 182 +++++
Platform/StMMRpmb/PlatformStandaloneMm.fdf | 111 +++
Drivers/OpTeeRpmb/FixupPcd.inf | 44 ++
Drivers/OpTeeRpmb/OpTeeRpmbFv.inf | 58 ++
Drivers/OpTeeRpmb/OpTeeRpmbFvb.h | 52 ++
Drivers/OpTeeRpmb/FixupPcd.c | 74 ++
Drivers/OpTeeRpmb/OpTeeRpmbFvb.c | 775 ++++++++++++++++++++
7 files changed, 1296 insertions(+)
create mode 100644 Platform/StMMRpmb/PlatformStandaloneMm.dsc
create mode 100644 Platform/StMMRpmb/PlatformStandaloneMm.fdf
create mode 100644 Drivers/OpTeeRpmb/FixupPcd.inf
create mode 100644 Drivers/OpTeeRpmb/OpTeeRpmbFv.inf
create mode 100644 Drivers/OpTeeRpmb/OpTeeRpmbFvb.h
create mode 100644 Drivers/OpTeeRpmb/FixupPcd.c
create mode 100644 Drivers/OpTeeRpmb/OpTeeRpmbFvb.c
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#66483): https://edk2.groups.io/g/devel/message/66483
Mute This Topic: https://groups.io/mt/77703661/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-