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-9066dc8d2...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
