From: Tim Schumacher <timschumi@gmx.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
Peter Jones <pjones@redhat.com>,
linux-efi@vger.kernel.org, Jeremy Kerr <jk@ozlabs.org>,
linux-kernel@vger.kernel.org, timschumi@gmx.de
Subject: Re: [PATCH] efivarfs: Iterate variables with increasing name buffer sizes
Date: Tue, 23 Jan 2024 18:33:00 +0100 [thread overview]
Message-ID: <b58a112f-767f-4918-8262-63ac1dbfebbf@gmx.de> (raw)
In-Reply-To: <CAMj1kXEKF_a6wLtoMYCwBKEVDo6k1u=Cas-=4Ar4WnANHNu+cg@mail.gmail.com>
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.
I'll look into updating it appropriately when doing my changes (or remove
it entirely, since it seems to serve no other purpose than justifying the
starting buffer size).
>> In regards to complexity of the proposed solution, how about we approach
>> this from the other side? Start off with advertising 1024 bytes of
>> buffer storage, and cut that value in half (without actually resizing
>> the buffer) as long as we get `EFI_INVALID_PARAMETER` while on the first
>> run.
>>
>> If we ever get `EFI_BUFFER_TOO_SMALL`, we know that something is wrong
>> with the UEFI implementation (because that either means that something
>> claims to be larger than 1024 bytes, or that our assumptions about the
>> quirk don't hold up) and can bail out and log as appropriate. That would
>> limit the complexity to the machines that need it, completely omit the
>> need for resize logic, and would still be specification compliant.
>
> Yes, I would prefer to keep this as simple as possible.
I'll prepare a v2 with those changes then. The 1024 bytes may not be
an actual limit, but I'll keep it as the default size for the second
revision to ensure that we don't break any existing setups.
If this is still considered not simple enough, we can go back to looking
at just doing s/1024/512/ for the static buffer size.
Thank you for the feedback, I greatly appreciate it.
Tim
PS: Apologies in case my previous message ended up with a messed up line
wrap. Thunderbird apparently shows the message with automatic line wrap
while composing, but doesn't actually send it like that (or lines are
magically unwrapped again when displaying the message afterwards).
next prev parent reply other threads:[~2024-01-23 17:33 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 [this message]
2024-01-24 21:25 ` Peter Jones
2024-01-25 8:12 ` Ard Biesheuvel
2024-04-13 10:47 ` Tim Schumacher
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=b58a112f-767f-4918-8262-63ac1dbfebbf@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