[PATCH 2/5 v2] efi_loader: Implement EFI variable handling via OP-TEE

Heinrich Schuchardt xypron.glpk at gmx.de
Fri May 15 13:55:35 CEST 2020


On 11.05.20 20:14, Ilias Apalodimas wrote:
> In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
> StandAloneMM is responsible for the UEFI variable support. In
> combination with OP-TEE and it's U-Boot supplicant, variables are
> authenticated/validated in secure world and stored on an RPMB partition.
>
> So let's add a new config option in U-Boot implementing the necessary
> calls to OP-TEE for the variable management.
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> Signed-off-by: Pipat Methavanitpong <pipat1010 at gmail.com>
> Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> ---
>  lib/efi_loader/Kconfig            |   9 +
>  lib/efi_loader/Makefile           |   4 +
>  lib/efi_loader/efi_variable_tee.c | 643 ++++++++++++++++++++++++++++++
>  3 files changed, 656 insertions(+)
>  create mode 100644 lib/efi_loader/efi_variable_tee.c
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 1cfa24ffcf72..e385cd0b9dae 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -164,4 +164,13 @@ config EFI_SECURE_BOOT
>  	  it is signed with a trusted key. To do that, you need to install,
>  	  at least, PK, KEK and db.
>
> +config EFI_MM_COMM_TEE
> +	bool "UEFI variables storage service via OP-TEE"
> +	depends on SUPPORT_EMMC_RPMB
> +	default n
> +	help
> +	  If OP-TEE is present and running StandAloneMM dispatch all UEFI variable
> +	  related operations to that. The application will verify, authenticate and
> +	  store the variables on an RPMB
> +
>  endif

Dear Ilias,

at least CONFIG_TEE=y is needed as dependency. Otherwise compiling fails.

If OP-TEE is not found:

=> bootefi hello
Unable to open OP-TEE session (err=-19)
mm_communicate failed!
Error: Cannot initialize UEFI sub-system, r = 3

I think it could be allowable to boot without variable support unless we
are in secure boot audit mode. So if CONFIG_EFI_SECURE_BOOT=n, maybe we
should be less strict. I guess it will end up in weighing user
friendliness against complexity. What are your ideas?

Best regards

Heinrich


More information about the U-Boot mailing list