[U-Boot] efi_loader: implementing non-volatile UEFI variables
xypron.glpk at gmx.de
Mon Jun 24 19:10:07 UTC 2019
On 6/24/19 8:50 PM, Wolfgang Denk wrote:
> Dear Heinrich,
> In message <7083d208-4b3c-7261-a03b-9066dc8d2009 at gmx.de> you wrote:
>> to be really useful UEFI variables should be available to the operating
>> system. This is not possible using U-Boot variables as storage.
> Oops? Is it possible that you are not aware of the
> tools/env/fw_env* code?
I am fully aware of this.
Think about secure boot. It is a bad idea to expose variables in this way.
> Of course U-Boot environment variables can be accessed (read and
> written) from Linux.
>>>> 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.
> And I agree on that. But even if it was not the case, having four
> different implementations for the same thing is .... sub-optiman.
We have a lot of things that can be disabled in U-Boot. Why should we
not be able to disable UEFI variables?
What Linaro is doing with OP-TEE makes sense to enable secure boot. But
it will be an ARM64 specific solution.
> And if the "volatile" feature is all that is missing when using
> environment variables, then this should be the road taken:
> - It avoids a complete new implementation
> - It can be added witrh very little effort
> - It would be just a minimal increase in memory footprinmt
> - It is useful for a lot of other pirposes as well.
> What are your agruments for _not_ taking this approach?
UEFI variables should be accessible via the UEFI runtime API and not via
some U-Boot specific hack which no other program but U-Boot cares about.
>> The best solution for UEFI variables would be to live in the secure part
>> of the ARM trusted firmware.
> You think too narrow. Not all the world is ARM, and not everyone
> uses ATF.
>> UEFI variables have both a name and a GUID as keys.
> Internally U-Boot variables are stored in a hash table; you could
> easily add GUID support. the external storage format is also simple
> enough. You could extend it in a compatible way for example from
> to something like
> of, if you don't want to waste another separator character, even
> Extending the env import parser and the env export code for this
> does not look like rocket science either.
>> Furthermore both
>> variable names and values are in UTF-16. So they are quite different to
>> U-Boot variables.
> Nothing in U-Boot prevents this. There is a number of ways to
> convert UTF-16 (or even any kind of binary data) to and from plain
> ASCII strings, and only your UEFI code needs to understand such
>> Look at this output:
>> -> printenv
>> => 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 ..
> I'm looking at it, but I don't understand what you want to show me
> All I can see is that this looks like something I would not want to
> use (read: I consider it ugly and think the design should be
>> This is worthwhile but insufficient to solve the UEFI problems.
> Could you please be so kine and clearly state what is lacking?
> So far I have found:
> - lack of "volatile" vs. "non-volatile"
> - lack of support for GUID
> - lack of support for UTF-16
> None of these should be difficult to add by small (or even minimal)
> extensions of the existing code, which would probaly also useful to
> others (at least some of them).
> So far, I see no killing point not an advantage that would justify
> adding a completly new implementation for a problem that has been
> solved before.
> Best regards,
> Wolfgang Denk
More information about the U-Boot