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

[Heinrich Schuchardt]

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.

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
>