On Thu, 19 Mar 2020 at 12:05, Leif Lindholm <[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) - "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 - 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 > / > Leif > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
