On 6/24/19 12:23 PM, Wolfgang Denk wrote:
Dear Heinrich,
In message 83a2d8c5-1b06-c502-8a63-dc3ca307deb8@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