Hi all,

This is an updated version of [0].

When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file.  At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.

For GetVariableRT  we copy runtime variables in RAM and expose them to
the OS. Add a Kconfig option and provide SetVariableRT using the same
memory back end. The OS will be responsible for syncing the RAM contents
to the file, otherwise any changes made during runtime won't persist
reboots.

It's worth noting that the variable store format is defined in EBBR [1]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.

The original RFC was just enabling the memory back end. This is a more
complete version and we should be able, with small adjustments of
userspace tools, fix SetVariableRT. If enabled the firmware will add two
new RO EFI variables after ExitBootServices.

RTStorageVolatile -- contains the filename, relative to the ESP
VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
be copied to the file defined by RTStorageVolatile.

If any errors occur during the variable init, the firmware will delete them
and adjust the RT_PROP table accordingly, disabling SetvarRT.

- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(ro,nosuid,nodev,noexec,relatime)

$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system

- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
, disabling SetvarRT.
$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* debian        
HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x100000)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0      
VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,850000001f000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,1600850000000000){auto_created_boot_option}

$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
        Non-Volatile
        Boot Service Access
        Runtime Service Access
Value:
00000000  01 00

[0] 
https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
[1] 
https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

Changes since the RFC:
- Return EFI_INVALID_PARAM if attributes are not volatile
- Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
- Add 2 EFI variables and allow userspace to write the file
- Add selftests

Ilias Apalodimas (4):
  efi_loader: conditionally enable SetvariableRT
  efi_loader: Add OS notifications for SetVariableRT in RAM
  efi_loader: add an EFI variable with the variable file contents
  efi_selftest: add tests for setvariableRT

 include/efi_loader.h                          |   4 +
 include/efi_variable.h                        |  15 +-
 lib/efi_loader/Kconfig                        |  16 ++
 lib/efi_loader/efi_boottime.c                 |   2 +
 lib/efi_loader/efi_runtime.c                  |   1 +
 lib/efi_loader/efi_var_common.c               |  43 ++--
 lib/efi_loader/efi_var_file.c                 |   1 -
 lib/efi_loader/efi_var_mem.c                  |  90 +++-----
 lib/efi_loader/efi_variable.c                 | 210 +++++++++++++++++-
 lib/efi_loader/efi_variable_tee.c             |   1 -
 .../efi_selftest_variables_runtime.c          | 116 +++++++++-
 11 files changed, 401 insertions(+), 98 deletions(-)

--
2.37.2

Reply via email to