Tianocore/edk2-platforms.git/Platform/StandaloneMm, branch CodeCleanup

PlatformStandaloneMmPkg: Add VariableFlashInfoLib

2022-05-19T03:46:19+00:00

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479 Adds an instance for the library class VariableFlashInfoLib that was recently introduced in MdeModulePkg. This change is made to allow the new variable driver to build that has a dependency on this library class and does not require any further platform changes. Cc: Sami Mujawar Cc: Ilias Apalodimas Signed-off-by: Michael Kubacki Reviewed-by: Michael D Kinney Reviewed-by: Sami Mujawar Reviewed-by: Ilias Apalodimas Acked-by: Ard Biesheuvel

Platform/StandaloneMm: build StandaloneMmRpmb for 32bit architectures

2021-08-11T11:44:10+00:00

Build PlatformStandaloneMmRpmb for ARM architecture (32bit arm machine). The generated image targets an execution environment similar to AArch64 StMM secure partition in OP-TEE but in 32bit mode. GCC flag -fno-stack-protector added. The stack protection code bring GOT dependencies we prefer avoid when StMM runs in OP-TEE. Cc: Ard Biesheuvel Cc: Ilias Apalodimas Cc: Leif Lindholm Cc: Sami Mujawar Signed-off-by: Etienne Carriere

Platform/StandaloneMm: sync with edk2 StandaloneMmCpu path change

2021-08-11T11:44:10+00:00

Synchronize with edk2 package where StandaloneMmCpu component has moved from StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf to StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf Cc: Ard Biesheuvel Cc: Ilias Apalodimas Cc: Leif Lindholm Cc: Sami Mujawar Cc: Sughosh Ganu Cc: Thomas Abraham Signed-off-by: Etienne Carriere

StMMRpmb: Add support for building StandaloneMm image for OP-TEE

2021-03-28T09:46:35+00:00

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] 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://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/ Reviewed-by: Sami Mujawar Signed-off-by: Ilias Apalodimas