On Thu, Mar 19, 2020 at 12:31:37 +0100, François Ozog wrote:
> On Thu, 19 Mar 2020 at 12:05, Leif Lindholm <[email protected]> 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.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
