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.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- 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.h... 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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture