On 3/19/20 12:05 PM, Leif Lindholm 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.
If the firmware that has no persistent storage but holds all variables in memory, an operating system shutdown service (e.g. a script in systemd's /usr/lib/systemd/system-shutdown/) could be used to persist the variables before reboot. The service would read all variable via Get(Next)Variable and write a file to the EFI boot partition. This could be an EFI update capsule or some system specific file format. Best regards Heinrich > > (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. > > / > Leif > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
