[U-Boot] efi_loader: implementing non-volatile UEFI variables
Heinrich Schuchardt
xypron.glpk at gmx.de
Thu Jun 20 08:06:44 UTC 2019
Hello Ilias,
thanks a lot for the good online meeting this morning together with your
colleague Suggan where we discussed the requirements for the
implementation of non-volatile variables in U-Boot.
Currently UEFI variables are stored in U-Boot variables. Saving the
U-Boot variables will persist all UEFI variables in the environment both
volatile and non-volatile. This does not conform the the UEFI standard.
To provide a secure storage Linaro is considering to implement an OP-TEE
module for variable storage and as alternative to this OP-TEE module a
standalone MM service which will be a BL32 ATF module.
So in future we will have possibly three alternative drivers for UEFI
variables:
- U-Boot only implementation
(what is now in lib/efi_loader/efi_variable.c)
- OP-TEE module
- standalone MM service
And maybe a fourth dummy one implementing no variable service at all.
To make the OP-TEE module and the standalone MM service usable in EDK2
too they will provide implementations for GetVariable(),
GetNextVariable(), QueryVariable(), and SetVariable() both for volatile
and non-volatile variables.
The U-Boot only implementation currently provides these variables only
at boottime. Takahiro sent patches with a runtime cache enabling
GetVariable(), GetNextVariable() and possibly in future QueryVariable()
but not SetVariable().
Currently when reaching SetVirtualAddressMap() we patch the runtime
table to replace the variable services by dummy functions returning
EFI_UNSUPPORTED (or at least this should be the return value). Alex
delivered a patch that will move this patching to ExitBootServices() to
comply with the requirements of operating systems which do not call
SetVirtualAddressMap().
As in future we will have three different drivers for variables and
these will differ in which runtime services they support it makes sense
to move the obligation of patching the runtime services table to the
variable driver itself. We already have implemented the event group
EFI_EVENT_GROUP_EXIT_BOOT_SERVICES. So if the driver creates an event
for this group it can do the patching in the notification function of
the event.
I will update the current variables implementation to take care of the
runtime services table patching for variable services using
EFI_EVENT_GROUP_EXIT_BOOT_SERVICES and add a null driver. This will
provide the templates for the U-Boot side implementation of the OP-TEE
and standalone MM service solution.
Once we have that API right we can start moving in Takahiros patches for
separating UEFI and U-Boot variables and creating a runtime cache.
Best regards
Heinrich
More information about the U-Boot
mailing list