All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Tim Schumacher <timschumi@gmx.de>
Cc: linux-efi@vger.kernel.org, Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [PATCH v2 4/4] efi: Clear up misconceptions about a maximum variable name size
Date: Fri, 29 Mar 2024 09:42:59 +0200	[thread overview]
Message-ID: <CAMj1kXGuQ2RCpyBdGfOsApT61syG=oeoNSUkmy3PCBnPkir8og@mail.gmail.com> (raw)
In-Reply-To: <20240328205041.76812-4-timschumi@gmx.de>

On Thu, 28 Mar 2024 at 22:51, Tim Schumacher <timschumi@gmx.de> wrote:
>
> The UEFI specification does not make any mention of a maximum variable
> name size, so the headers and implementation shouldn't claim that one
> exists either.
>
> Comments referring to this limit have been removed or rewritten, as this
> is an implementation detail local to the Linux kernel.
>
> Where appropriate, the magic value of 1024 has been replaced with
> EFI_VAR_NAME_LEN, as this is used for the efi_variable struct
> definition. This in itself does not change any behavior, but should
> serve as points of interest when making future changes in the same area.
>
> A related build-time check has been added to ensure that the special
> 512 byte sized buffer will not overflow with a potentially decreased
> EFI_VAR_NAME_LEN.
>
> Signed-off-by: Tim Schumacher <timschumi@gmx.de>

Thanks for resending. I've queued these up now.

> ---
> Changes from v1:
>  - None, resubmitted as part of a patch chain
> ---
>  drivers/firmware/efi/vars.c | 2 +-
>  fs/efivarfs/vars.c          | 5 +++--
>  include/linux/efi.h         | 9 ++++-----
>  3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index f654e6f6af873..4056ba7f34408 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -215,7 +215,7 @@ efi_status_t efivar_set_variable_locked(efi_char16_t *name, efi_guid_t *vendor,
>
>         if (data_size > 0) {
>                 status = check_var_size(nonblocking, attr,
> -                                       data_size + ucs2_strsize(name, 1024));
> +                                       data_size + ucs2_strsize(name, EFI_VAR_NAME_LEN));
>                 if (status != EFI_SUCCESS)
>                         return status;
>         }
> diff --git a/fs/efivarfs/vars.c b/fs/efivarfs/vars.c
> index 4d722af1014f2..3cc89bb624f07 100644
> --- a/fs/efivarfs/vars.c
> +++ b/fs/efivarfs/vars.c
> @@ -295,9 +295,9 @@ static bool variable_is_present(efi_char16_t *variable_name, efi_guid_t *vendor,
>         unsigned long strsize1, strsize2;
>         bool found = false;
>
> -       strsize1 = ucs2_strsize(variable_name, 1024);
> +       strsize1 = ucs2_strsize(variable_name, EFI_VAR_NAME_LEN);
>         list_for_each_entry_safe(entry, n, head, list) {
> -               strsize2 = ucs2_strsize(entry->var.VariableName, 1024);
> +               strsize2 = ucs2_strsize(entry->var.VariableName, EFI_VAR_NAME_LEN);
>                 if (strsize1 == strsize2 &&
>                         !memcmp(variable_name, &(entry->var.VariableName),
>                                 strsize2) &&
> @@ -396,6 +396,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *,
>
>         do {
>                 variable_name_size = 512;
> +               BUILD_BUG_ON(EFI_VAR_NAME_LEN < 512);
>
>                 status = efivar_get_next_variable(&variable_name_size,
>                                                   variable_name,
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index d59b0947fba08..418e555459da7 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1072,12 +1072,11 @@ static inline u64 efivar_reserved_space(void) { return 0; }
>  #endif
>
>  /*
> - * The maximum size of VariableName + Data = 1024
> - * Therefore, it's reasonable to save that much
> - * space in each part of the structure,
> - * and we use a page for reading/writing.
> + * There is no actual upper limit specified for the variable name size.
> + *
> + * This limit exists only for practical purposes, since name conversions
> + * are bounds-checked and name data is occasionally stored in-line.
>   */
> -
>  #define EFI_VAR_NAME_LEN       1024
>
>  int efivars_register(struct efivars *efivars,
> --
> 2.44.0
>

      reply	other threads:[~2024-03-29  7:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-15  0:25 [PATCH 1/3] efi: pstore: Request at most 512 bytes for variable names Tim Schumacher
2024-03-15  0:25 ` [PATCH 2/3] efivarfs: Remove unused internal struct members Tim Schumacher
2024-03-15  9:19   ` Ard Biesheuvel
2024-03-15 18:52     ` Tim Schumacher
2024-03-15  0:26 ` [PATCH 3/3] efi: Clear up misconceptions about a maximum variable name size Tim Schumacher
2024-03-15  9:20   ` Ard Biesheuvel
2024-03-15 19:45     ` Tim Schumacher
2024-03-15  9:16 ` [PATCH 1/3] efi: pstore: Request at most 512 bytes for variable names Ard Biesheuvel
2024-03-15 19:02   ` Tim Schumacher
2024-03-15 19:45   ` Guilherme G. Piccoli
2024-03-29  7:34     ` Ard Biesheuvel
2024-03-29 21:32       ` Guilherme G. Piccoli
2024-03-28 20:50 ` [PATCH v2 1/4] " Tim Schumacher
2024-03-28 20:50   ` [PATCH v2 2/4] Documentation: Mark the 'efivars' sysfs interface as removed Tim Schumacher
2024-03-28 20:50   ` [PATCH v2 3/4] efivarfs: Remove unused internal struct members Tim Schumacher
2024-03-28 20:50   ` [PATCH v2 4/4] efi: Clear up misconceptions about a maximum variable name size Tim Schumacher
2024-03-29  7:42     ` Ard Biesheuvel [this message]

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='CAMj1kXGuQ2RCpyBdGfOsApT61syG=oeoNSUkmy3PCBnPkir8og@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=timschumi@gmx.de \
    /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.