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

Tue Jun 25 01:10:40 UTC 2019

On Mon, Jun 24, 2019 at 09:10:07PM +0200, Heinrich Schuchardt wrote:
> 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.

Oops, I don't know, but

> Think about secure boot. It is a bad idea to expose variables in this way.

Actually, we are thinking of disabling U-Boot environment (I mean,
ENV_IS_NOWHERE) still allowing for UEFI variables for security reason.

One of the differences between U-Boot env and UEFI variables
is that the former can and should be saved to backing storage
only with explicit "saveenv" command, while the latter are
expected to be saved immediately.

Preserving respective semantics simultaneously would be possible, but
it would make the implementation a bit complicated and ugly.
Instead, I believe that it will be a clever idea that we should have
separate contexts for them as I showed in my non-volatile support patch[1].

[1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html

One of possible improvements here is to refactor the env code and
parameterize "contexts" at env_save()/env_load().

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

To be honest, I'm a bit doubtful about practical meaning of
disabling UEFI variables for UEFI execution environment.

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

See my comment above.

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

Please notice that one of the reasons that prevents UEFI variables
from being accessed by OS is a real hardware(device/controller) may be
shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive
access must be ensured.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >
> >>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
> >
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot