On 3/19/20 12:31 PM, François Ozog wrote: > > > On Thu, 19 Mar 2020 at 12:05, Leif Lindholm <[email protected] > <mailto:[email protected]>> wrote: > > Hi Ilias, > > On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote: > > On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote: > > > > > As some of you may know, I'm going to submit a RFC patch > series for UEFI > > > > > capsule support on U-Boot in a week or so (maybe). With this > patch, > > > > > we will support "Capsule-on-Disk" only (but without > authentication > > > > > implemented). > > > > > > > > > > One of my concerns here is about "variable update via a > capsule" as > > > > > an alternative of "SetVariable at runtime," where values to > be set > > > > > for variables will be exported as a capsule file and all the > updates > > > > > will take place after rebooting. This is very useful on systems > > > > > where SetVariable is not available at runtime for some reasons. > > > > > Some idea has been proposed by Peter[1], but the discussion > has been > > > > > stalled for a long time. > > > > > > > > > > [1] > > https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > > > > > > > So the way i understand it we got two paths we can follow: > > > > 1. Use a configuration table for those variables > > > > 2. Shadow the variables on a kernel accessible memory in order > to have access to > > > > them > > > > > > It is unclear to me why it would be advantageous to follow any > of these > > > ideas compared to using GetVariable and SetVariable and letting the > > > firmware runtime manage the memory area. > > > > This describes some of the reasoning behind the idea. > > > > https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.html > > The short version is that we should be able to provide > GetVariable() even if > > SetVariable() is not implemented. > > 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)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them? > - "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. Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr. > - UEFI variables interface for tools/kernel must not change: get/set > variable > - implementation of getVariable accesses a copy/shadow version of the > UEFI variable > - implementation of setVariable actually generates an update capsule so > that the variable update is seen at next reboot The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates. A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot. Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do. Best regards Heinrich _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
