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

[Wolfgang Denk]

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?

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.

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?

> 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

	<name>=<value>\0

to something like

	<name>;<guid>=<value>\0

of, if you don't want to waste another separator character, even

	<name>=<guid>=<value>\0

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

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

I'm looking at it, but I don't understand what you want to show me
here?

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
improved).

> 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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Everyone, in some small sacred sanctuary of the self, is nuts.
                                                         - Leo Rosten