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@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@lists.denx.de https://lists.denx.de/listinfo/u-boot