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, Kees Cook <keescook@chromium.org>,
	 Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	 linux-hardening@vger.kernel.org
Subject: Re: [PATCH 1/3] efi: pstore: Request at most 512 bytes for variable names
Date: Fri, 15 Mar 2024 10:16:59 +0100	[thread overview]
Message-ID: <CAMj1kXEvQS8e95A55po-nKn8cGou8Dn9nNhidt_QSqL02WawpQ@mail.gmail.com> (raw)
In-Reply-To: <20240315002616.422802-1-timschumi@gmx.de>

Hi Tim,

On Fri, 15 Mar 2024 at 01:27, Tim Schumacher <timschumi@gmx.de> wrote:
>
> Work around a quirk in a few old (2011-ish) UEFI implementations, where
> a call to `GetNextVariableName` with a buffer size larger than 512 bytes
> will always return EFI_INVALID_PARAMETER.
>
> This was already done to efivarfs in f45812cc23fb ("efivarfs: Request at
> most 512 bytes for variable names"), but the second copy of the variable
> iteration implementation was overlooked.
>
> Signed-off-by: Tim Schumacher <timschumi@gmx.de>

Thanks for the patch. I'll take it as a fix.

As an aside, you really want to avoid EFI pstore in general, and
specifically on such old systems with quirky UEFI implementations.

> ---
> I CC'd the pstore people and linux-hardening mailing list because
> get_maintainer.pl suggested to do so. Apologies in case this was the
> incorrect decision, this is a very non-pstore-specific patch after all.
>

If any of the linux-hardening/pstore people give you grief, just send
them to me :-)

(I am part of the linux-hardening group myself, and work closely with Kees)


> I have taken the liberty of adding a TODO for the future, the actual
> refactor can follow at some point down the line.
> ---
>  drivers/firmware/efi/efi-pstore.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c
> index e7b9ec6f8a86..f0ceb5702d21 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -135,7 +135,15 @@ static ssize_t efi_pstore_read(struct pstore_record *record)
>         efi_status_t status;
>
>         for (;;) {
> -               varname_size = 1024;
> +               /*
> +                * 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,
> --
> 2.44.0
>

  parent reply	other threads:[~2024-03-15  9:17 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 ` Ard Biesheuvel [this message]
2024-03-15 19:02   ` [PATCH 1/3] efi: pstore: Request at most 512 bytes for variable names 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

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=CAMj1kXEvQS8e95A55po-nKn8cGou8Dn9nNhidt_QSqL02WawpQ@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=timschumi@gmx.de \
    --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.