[PATCH 1/2] efi: loader: don't let VarToFile stop the variable file from being written

[PATCH 1/2] efi: loader: don't let VarToFile stop the variable file from being written

[Ahmad Fatoum]

efi_var_collect() walks the variable store with GetNextVariableName() and
reads every variable it finds into a buffer the size of the store, then
keeps only those matching the attribute mask. Reading a variable whose
value does not fit aborts the collection, and with it the write of the
variable file:

  efi-loader: var-file: Failed to persist EFI variables Out of memory

VarToFile is such a variable. Its value is not stored anywhere: reading
it serializes all non-volatile variables, so it needed as much room as
everything collected before it.

Assisted-by: Claude:opus-5
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 efi/loader/efi_var_common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/efi/loader/efi_var_common.c b/efi/loader/efi_var_common.c
index 4c6cb77e7c2c..dcdfa6fb0165 100644
--- a/efi/loader/efi_var_common.c
+++ b/efi/loader/efi_var_common.c
@@ -454,6 +454,14 @@ efi_status_t __maybe_unused efi_var_collect(struct efi_var_file **bufp, loff_t *
 		ret = efi_get_variable_int(var->name, &var->guid,
 					   &var->attr, &data_length, data,
 					   &var->time);
+		/*
+		 * The attributes are valid even when the value did not fit.
+		 * Variables we are not going to keep may thus be skipped
+		 * without their value ever being copied, e.g. VarToFile.
+		 */
+		if (ret == EFI_BUFFER_TOO_SMALL &&
+		    (var->attr & check_attr_mask) != check_attr_mask)
+			continue;
 		if (ret != EFI_SUCCESS) {
 			free(buf);
 			return ret;
-- 
2.47.3

[PATCH 2/2] efi: loader: keep booting when the runtime variable store is unavailable

[Ahmad Fatoum]

efi_init_runtime_variable_supported() creates the two variables the OS
needs to write the variable file itself: RTStorageVolatile names the file
on the ESP and VarToFile hands out its contents. Both are inserted into
the same 128 KiB in-memory store as every other variable, so both fail
with EFI_OUT_OF_RESOURCES once that store is full.

The loader itself does not need those variables, only runtime
SetVariable() does. Warn and clear EFI_RT_SUPPORTED_SET_VARIABLE in the
runtime properties table instead, so the OS is told that persisting
variables at runtime is not available, and boot on.

Assisted-by: Claude:opus-5
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 efi/loader/runtime.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/efi/loader/runtime.c b/efi/loader/runtime.c
index f0fbd263fe55..a33db166d064 100644
--- a/efi/loader/runtime.c
+++ b/efi/loader/runtime.c
@@ -72,8 +72,10 @@ efi_status_t efi_init_runtime_supported(void)
 		CHECK_RT_FLAG(QUERY_VARIABLE_INFO);
 
 	ret = efi_init_runtime_variable_supported();
-	if (ret != EFI_SUCCESS)
-		return ret;
+	if (ret != EFI_SUCCESS) {
+		pr_warn("no runtime variable store: %s\n", efi_strerror(ret));
+		rt_table->runtime_services_supported &= ~EFI_RT_SUPPORTED_SET_VARIABLE;
+	}
 
 	return efi_install_configuration_table(&efi_rt_properties_table_guid, rt_table);
 }
-- 
2.47.3

Re: [PATCH 1/2] efi: loader: don't let VarToFile stop the variable file from being written

[Sascha Hauer]

On Wed, 26 Aug 2026 11:47:57 +0200, Ahmad Fatoum wrote:
> efi_var_collect() walks the variable store with GetNextVariableName() and
> reads every variable it finds into a buffer the size of the store, then
> keeps only those matching the attribute mask. Reading a variable whose
> value does not fit aborts the collection, and with it the write of the
> variable file:
> 
>   efi-loader: var-file: Failed to persist EFI variables Out of memory
> 
> [...]

Applied, thanks!

[1/2] efi: loader: don't let VarToFile stop the variable file from being written
      https://git.pengutronix.de/cgit/barebox/commit/?id=655c59531037 (link may not be stable)
[2/2] efi: loader: keep booting when the runtime variable store is unavailable
      https://git.pengutronix.de/cgit/barebox/commit/?id=b6ce84a22fe5 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>