Repository navigation
Describe runtime access to file-backed variable stores - #169
Conversation
|
Hi @ricardosalveti, shall we discuss this pull request during our EBBR call of Sep 9 if that helps? |
Sure, that should be fine. |
|
Hello Ricardo, thank you for contributing this suggestion. I think we can make GetVariable(), GetNextVariable(), and QueryVariableInfo required both before and after ExitBootServices(). SetVariable() with efivar support only works for use cases where the efivar lib is used. It is a nice hack which works for GRUB and efibootmgr but will fail for any application directly talking to the kernel. Other operating systems like Windows will never support it. As EBBR is a firmware spec it should not impose requirements on an OS. Best regards Heinrich |
vstehle
left a comment
vstehle
left a comment
There was a problem hiding this comment.
To follow up with the EBBR call of Sep 9, we would like to suggest the following changes:
- Move to a different section (e.g. under chapter 5)
- Mention the U-Boot/libefivar method as an example only, do not require or make it mandatory
0e9abfd to
4ee594d
Compare
ricardosalveti
changed the title
|
Hi, sorry for the delay.
Agreed, and reworked following the call notes: table is back to "Optional" for all three services, the chapter 2 requirement is gone (replaced by a note pointing to chapter 5), and chapter 5 now describes the u-boot / libefivar mechanism as an informative example, with the limitation spelled out that only software aware of the mechanism |
Sure, reworked as discussed on Sep 9: nothing is required anymore. Chapter 5 describes the u-boot / libefivar mechanism, variables included, in an informative section as an example only, and chapter 2 keeps the runtime services table unchanged and only points to that section in a note. Move to review again, from draft. |
4ee594d to
2b61677
Compare
|
@xypron thanks for the review, updated the pr reflecting your comments. |
|
Thank you @ricardosalveti, overall this looks good to me. |
2b61677 to
4d4f103
Compare
Firmware that stores EFI variables in a file cannot write that file once the OS controls the storage device. U-Boot can keep servicing the variable runtime services from a memory-backed store and delegate persisting it to the OS: the RTStorageVolatile variable names the store file on the ESP and VarToFile exports the content the file must have. libefivar supports the mechanism (rhboot/efivar#282), but it is not documented outside of the U-Boot sources. Describe the mechanism in a non-normative section, as an example of how the variable store file can be updated at runtime, with U-Boot and libefivar as example implementations of the firmware and OS sides, without making it, or the variables it relies on, an EBBR requirement, and record its limitations: only modifications made by software aware of the mechanism persist across reset. While at it, retitle the chapter, whose scope now goes beyond the store file format, and add the chapter 2 anchor the new section refers to. This follows up on the discussion in ARM-software#143. Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com>
The Runtime Variable Access section recommends caching the variables in memory so that GetVariable() and GetNextVariableName() keep working when SetVariable() is not supported during runtime services. Add a note mentioning that firmware can go one step further and also accept SetVariable() on the cached copy, relying on the OS to persist the variable store, and point to the example now described in chapter 5. This is not a generic solution and is not required by EBBR: the runtime services requirements are unchanged. Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com>
4d4f103 to
9ba1042
Compare
|
@vstehle updated, let me know if additional changes are required. |
|
Thank you @ricardosalveti; merging as per our EBBR call of Oct 7. |
3 participants
Describe the mechanism U-Boot uses to keep SetVariable() available at
runtime with a file-backed variable store, following up on #143 and the
EBBR call of Sep 9: the firmware services the variable runtime services
from memory and exports the store file content through two volatile
variables, RTStorageVolatile and VarToFile, which the OS writes back to
the ESP. libefivar supports it since rhboot/efivar#282 (systemd doesn't
use libefivar; equivalent support is proposed in systemd/systemd#42905).
Chapter 5 describes the mechanism, variables included, in an informative
section as an example only, and records its limitations (only software
aware of the mechanism persists its changes). Chapter 2 keeps the runtime
services table unchanged and only points to that section in a note.
Nothing is required from firmware or the OS.