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

[Heinrich Schuchardt]

On 6/24/19 12:23 PM, Wolfgang Denk wrote:
> Dear Heinrich,
>
> In message <83a2d8c5-1b06-c502-8a63-dc3ca307deb8 at gmx.de> you wrote:
>>
>> 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.
>
> Is this the only problem of using the environment as storage?

Dear Wolfgang,

to be really useful UEFI variables should be available to the operating
system. This is not possible using U-Boot variables as storage.

>
>> 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.
>
> Is this really a good idea?

Tom is always complaining that the UEFI subsystem has become too large.
As GRUB and Linux boot without UEFI variables they are one possibility
to size down the image. But I would not choose this config option by
default.

>
> If the volatile / non-volatile behaviour is the only problem you
> see with using environment variables, would it then not make much
> more sense to extend the environment flags concept by adding a
> "volatile" flag, with the meaning that such variables don't get
> written by "env save"?

The best solution for UEFI variables would be to live in the secure part
of the ARM trusted firmware.

UEFI variables have both a name and a GUID as keys. Furthermore both
variable names and values are in UTF-16. So they are quite different to
U-Boot variables.

Look at this output:

=> printenv

efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)0000000000000000
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004

=> printenv -e

OsIndicationsSupported: BS|RT, DataSize = 0x8
     00000000: 00 00 00 00 00 00 00 00                          ........
PlatformLang: NV|BS|RT, DataSize = 0x6
     00000000: 65 6e 2d 55 53 00                                en-US.
PlatformLangCodes: BS|RT, DataSize = 0x6
     00000000: 65 6e 2d 55 53 00                                en-US.
RuntimeServicesSupported: BS|RT, DataSize = 0x2
     00000000: 80 04                                            ..

>
> This would also make sense in some other places - for example, the
> "filesize" variable is a perfect candidate to be flagged as
> "volatile".  There is absolutely no use in saving it persistently.
>
> So such an extension would be useful for others, too, and might
> eventually avoid so many different implementations for the same
> task?  Also, the implementation should be straightforward...
>

This is worthwhile but insufficient to solve the UEFI problems.

Best regards

Heinrich