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

Tue Jun 25 04:41:27 UTC 2019

On 6/25/19 3:10 AM, AKASHI Takahiro wrote:
> 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.

I will drop
https://lists.denx.de/pipermail/u-boot/2019-June/373915.html
"efi_debug: make variable support customizable"
to stop that discussion. We still can introduce the customization option
once the OP-TEE option has been worked out.

Concerning your patch
https://lists.denx.de/pipermail/u-boot/2019-June/371602.html
"env: save UEFI non-volatile variables in dedicated storage"
What do you think about Wolfgang's propositions below to adjust
env_save() to provide a volatile/non-volatile flag for normal U-Boot
variables?

Best regards

Heinrich

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