[U-Boot] efi_loader: implementing non-volatile UEFI variables

[Ilias Apalodimas]

Hi Heinrich,

(+ Sughosh and Francois)


On Thu, 20 Jun 2019 at 11:06, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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
StandaloneMM will run as an application (trusted application or in
short TA) in OP-TEE.
So this two options are actually one.
Please note that this approach will offer identical functionality for
Armv7 and Armv8 architectures.
The current StandaloneMM implementation in EDKII run in SPM (and not
OP-TEE) so it's only usable on armv8

>
> 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().
Correct, we are currently considering not enabling SetVariable in
runtime, but only update UEFI variables on next-boot

>
> 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

Thanks for the meeting. If you need any future sync-ups please let me know

Regards
/Ilias