On Thu, Mar 19, 2020 at 12:31:37 +0100, François Ozog wrote:
On Thu, 19 Mar 2020 at 12:05, Leif Lindholm leif@nuviainc.com wrote:
I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems.
Systems that support GetVariable need to support that without any special handling added to the kernel.
For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area.
Similarly, for such systems to support SetVariable they will need to either:
- allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write.
- allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent.
(The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.)
How and when any transactions become persisted in flash are separate questions.
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably moving away from this (Grant told us that at a design sprint a year ago)
I'm pretty sure Grant said *UEFI*[0] might move away from them (if not, bad Grant!). I think a more accurate description would be that UEFI *wants* to move away from them. Even so, that's a push, and runtime services are certainly going to remain relevant for the next decade or two.
Discussing what may or may not happen is not an argument for diverging from the existing specification, nor is it constructive to discuss bolt-ons onto the side of the spec other than in the context of proposing specific changes to the UEFI specification.
- "system administrator" is not the trusted party that has authority to change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
- UEFI variables interface for tools/kernel must not change: get/set variable
Yes, this is the sticking point. GetVariable/SetVariable (where supported) must be implemented as runtime services accessed through pointers in the EFI System Table. No alternative mechanisms for getting/setting UEFI variables must be implemented unless supported by a future UEFI specification.
- implementation of getVariable accesses a copy/shadow version of the UEFI variable
Yep. Without any knowledge on behalf of the operating system beyond the addresses of the runtime service functions.
- implementation of setVariable actually generates an update capsule so that the variable update is seen at next reboot
I don't really have an opinion[1] - my statement was intended to separate the discussion of the interfaces for accessing variables at runtime from the discussion of mechanisms used to persist said variables in a single-storage system.
/ Leif
[0] EDK2 is the reference implementation of UEFI, it isn't going to go off and invent interfaces that aren't already resolved in the spec.
[1] This is obviously a lie.