From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Jonggeun Park" <jakejgpark@gmail.com>, "Jeremy Kerr" <jk@ozlabs.org>
Cc: "Kees Cook" <kees@kernel.org>, "Tony Luck" <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] efi: vars: commonize the 512-byte name buffer quirk
Date: Thu, 03 Sep 2026 11:55:06 +0200 [thread overview]
Message-ID: <b567665e-9792-42e1-a37a-3ea245ccf9bd@app.fastmail.com> (raw)
In-Reply-To: <20260815074844.1330-1-jakejgpark@gmail.com>
Hello Jonggeun,
On Sat, 15 Aug 2026, at 09:48, Jonggeun Park wrote:
> Some old UEFI implementations reject GetNextVariableName() calls with
> a name buffer size larger than 512 bytes. Both efivar_init() and
> efi_pstore_read() open-code the same workaround of resetting the size
> to 512 on every iteration.
>
> Introduce efivar_get_next_variable_safe() which keeps this quirk in a
> single place, resolving the TODO in efi-pstore.c.
>
> No functional change intended.
>
> Signed-off-by: Jonggeun Park <jakejgpark@gmail.com>
> ---
> drivers/firmware/efi/efi-pstore.c | 16 +++++-----------
> drivers/firmware/efi/vars.c | 21 +++++++++++++++++++++
> fs/efivarfs/vars.c | 4 +---
> include/linux/efi.h | 4 ++++
> 4 files changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c
> b/drivers/firmware/efi/efi-pstore.c
> index a5db3534f..a135d6e2f 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -164,16 +164,6 @@ static ssize_t efi_pstore_read(struct
> pstore_record *record)
> efi_status_t status;
>
> for (;;) {
> - /*
> - * A small set of old UEFI implementations reject sizes
> - * above a certain threshold, the lowest seen in the wild
> - * is 512.
> - *
> - * TODO: Commonize with the iteration implementation in
> - * fs/efivarfs to keep all the quirks in one place.
> - */
> - varname_size = 512;
> -
> /*
> * If this is the first read() call in the pstore enumeration,
> * varname will be the empty string, and the GetNextVariable()
> @@ -185,8 +175,12 @@ static ssize_t efi_pstore_read(struct
> pstore_record *record)
> * store varname in record->psi->data. Given that we only
> * enumerate variables with the efi-pstore GUID, there is no
> * need to record the guid return value.
> + *
> + * The 512-byte name buffer quirk is handled inside
> + * efivar_get_next_variable_safe().
> */
> - status = efivar_get_next_variable(&varname_size, varname, &guid);
> + status = efivar_get_next_variable_safe(&varname_size, varname,
> + &guid);
> if (status == EFI_NOT_FOUND)
> return 0;
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 3700e9869..8e69f3632 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -265,3 +265,24 @@ efi_status_t efivar_query_variable_info(u32 attr,
> remaining_space, max_variable_size);
> }
> EXPORT_SYMBOL_NS_GPL(efivar_query_variable_info, "EFIVAR");
> +
> +/*
> + * efivar_get_next_variable_safe() - enumerate the next name/vendor
> pair
> + *
> + * Wrapper around efivar_get_next_variable() that keeps the 512-byte
> name
> + * buffer quirk in one place. Some old UEFI implementations reject
> name buffer
> + * sizes larger than 512 bytes (the lowest seen in the wild), so this
> always
> + * requests 512 bytes; callers must provide a buffer of at least that
> size.
> + *
> + * Must be called with efivars_lock held.
> + */
> +efi_status_t efivar_get_next_variable_safe(unsigned long *name_size,
> + efi_char16_t *name,
> + efi_guid_t *vendor)
> +{
> + BUILD_BUG_ON(EFI_VAR_NAME_LEN < 512);
> + *name_size = 512;
> +
> + return efivar_get_next_variable(name_size, name, vendor);
> +}
> +EXPORT_SYMBOL_NS_GPL(efivar_get_next_variable_safe, "EFIVAR");
Don't add a new function here - just move the logic into the existing
efivar_get_next_variable(), which has only two callers.
next prev parent reply other threads:[~2026-09-03 9:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 7:48 [PATCH] efi: vars: commonize the 512-byte name buffer quirk Jonggeun Park
2026-09-03 9:55 ` Ard Biesheuvel [this message]
2026-09-03 11:55 ` [PATCH v2] " Jonggeun Park
2026-09-03 20:03 ` Ard Biesheuvel
2026-09-03 21:28 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b567665e-9792-42e1-a37a-3ea245ccf9bd@app.fastmail.com \
--to=ardb@kernel.org \
--cc=gpiccoli@igalia.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jakejgpark@gmail.com \
--cc=jk@ozlabs.org \
--cc=kees@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.