Linux EFI development
 help / color / mirror / Atom feed
From: Tim Schumacher <timschumi@gmx.de>
To: Peter Jones <pjones@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-efi@vger.kernel.org, Jeremy Kerr <jk@ozlabs.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] efivarfs: Iterate variables with increasing name buffer sizes
Date: Sat, 13 Apr 2024 12:47:21 +0200	[thread overview]
Message-ID: <ef107046-200c-48fc-b678-eb06c1224940@gmx.de> (raw)
In-Reply-To: <CA+g+hrh_REk-bcTt-D+eSngofxdejeRXuXKhf1O15wzn+qMy6Q@mail.gmail.com>

On 24.01.24 22:25, Peter Jones wrote:
> On Tue, Jan 23, 2024 at 12:33 PM Tim Schumacher <timschumi@gmx.de> wrote:
>>
>> On 23.01.24 15:09, Ard Biesheuvel wrote:
>>> On Tue, 23 Jan 2024 at 14:55, Tim Schumacher <timschumi@gmx.de> wrote:
>>>>
>>>> I'd rather avoid introducing deviations from the specifications on the
>>>> kernel side as well.
>>>
>>> Which specification would this deviate from?
>>
>> The preexisting comment claims "Per EFI spec", and it appears that I got
>> mislead by that. Neither the UEFI specification, nor the newest revision
>> of the EFI specification (which I guess is what would have been current
>> back in 2004, when this comment was introduced) seem to make any mention
>> of a maximum length for the variable name.
>
> Curiously, I can't find it in the 1.02 spec (the oldest I can find)
> either.  When I inherited efibootmgr around 2013, this was a
> limitation there, but I don't see anything in that tree that claims
> it's a spec limitation either.  My suspicion is this is a former
> Itanium firmware limit that got promoted to "the spec says" by word of
> mouth, or was in some very early ia64 implementation spec.

In case anyone is still curious about this, I managed to track down where
the supposed limit actually came from.

The efivarfs documentation claims that "The old sysfs EFI variables code only
supported variables of up to 1024 bytes. This limitation existed in version
0.99 of the EFI specification, but was removed before any full releases."

With some effort I managed to track down a copy of EFI v0.99 [1], which
indeed says the following:

"The size of the VariableName, including the Unicode Null in bytes plus the
  DataSize is limited to a maximum size of 1024 bytes."

This note was there at least in version 0.92 and 0.99, and gone in at least
version 1.02. I haven't been able to find a copy of version 1.01, but it most
likely never even existed online, given that 1.02 happened only 12 days later
(and for the sole reason of "legal and trademarking requirements").
The EFI 0.99 errata (which might have included more details) sadly doesn't seem
to have been backed up anywhere by third-parties.

Tim

[1] Searching for "EFISpec_V099" on your preferred search engine should
     find it. I doubt that Intel will care about copyright assignments for
     feedback on 0.99 now, but the agreement prompt sadly prevented the Web
     Archive from reaching it.

  parent reply	other threads:[~2024-04-13 10:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 23:15 [PATCH] efivarfs: Iterate variables with increasing name buffer sizes Tim Schumacher
2024-01-23 11:24 ` Ard Biesheuvel
2024-01-23 13:55   ` Tim Schumacher
2024-01-23 14:09     ` Ard Biesheuvel
2024-01-23 17:33       ` Tim Schumacher
2024-01-24 21:25         ` Peter Jones
2024-01-25  8:12           ` Ard Biesheuvel
2024-04-13 10:47           ` Tim Schumacher [this message]
2024-01-23 20:27 ` [PATCH v2] efivarfs: Halve name buffer size until first successful response Tim Schumacher
2024-01-26 16:25   ` [PATCH v3] efivarfs: Request at most 512 bytes for variable names Tim Schumacher
2024-01-26 16:35     ` Ard Biesheuvel
2024-01-26 18:02       ` Tim Schumacher
2024-01-30 16:00         ` Tim Schumacher
2024-02-14 15:18           ` 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=ef107046-200c-48fc-b678-eb06c1224940@gmx.de \
    --to=timschumi@gmx.de \
    --cc=ardb@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=pjones@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox