Received-SPF: pass (google.com: domain of linux-kernel+bounces-35784-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <b58a112f-767f-4918-8262-63ac1dbfebbf@gmx.de>
Date: Tue, 23 Jan 2024 18:33:00 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] efivarfs: Iterate variables with increasing name buffer
 sizes
Content-Language: en-US
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
References: <20240122231507.1307793-1-timschumi@gmx.de>
 <CAMj1kXHSSRacU3hp6D3sdUKDESi1FoD33Qi=5Df+=_biZ-vqhA@mail.gmail.com>
 <223a4e75-2e06-4bc6-a70c-823f0eb308d7@gmx.de>
 <CAMj1kXEKF_a6wLtoMYCwBKEVDo6k1u=Cas-=4Ar4WnANHNu+cg@mail.gmail.com>
From: Tim Schumacher <timschumi@gmx.de>
In-Reply-To: <CAMj1kXEKF_a6wLtoMYCwBKEVDo6k1u=Cas-=4Ar4WnANHNu+cg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:HGf5fHXhNAQ=;vQCG0pYDuT95aDxR/yC+WTgX1Ln
 XBnGKoGAz+AmKD3j8pFeqn+gQatPfqw/VsZCaSlF+iEjJkKWdVzw5hHTMtlEW2XqdugSUvqzs
 xJMUhAfGTmauMlZpgMADbaC4X8e3lfnU+N9n9uqw4CWI1aOVVo+c5ikpCbUquR88Q0F/WMMp1
 pbEiuW5Pi+RpZyvPi8o3pJE009NKzOXOYKWkpHdyvP9tyQHphcbKQEaPmh6CZRMLJROpc9qyq
 NgWb0RcwNj832UBQv1rDssKMLrYA6d6HruLXT+iAkUwEcreH0sH8RmqJmj/JL59xSFJXAdHUo
 B37dtWaA3SEqmapRANRKzWr4W4ZoukNl5oEIUGKJ/TFEcJi/tSEHNxwCN+RRoPKMZz+iRRa9e
 w8gMPiWT68xu/vp1NmlkPBisrHb8WhoaZKr3NXmJufSFjND1qiPoGUGFWAL5kT70CnC5d6OcH
 /PSJXPRnmeRlVyHes/SNoeqB8XmPvIS7DpkpkhR6lAeFbLFzJg75uglsWx5O/7TmVnayfzDPF
 Oyzt2X1ElNlnheUt0WmKerXW/MhSfzbY6DCRJJ20cDALVbP8gULTS3NhM+UzFvLmqcQm6ow4N
 9NWgb6XISQ9bmpL3liv+Z0PjwU+e0LNKniexcxwlObGEXlrr8yVMIKLpWQRoKdF0nWcEBQAnt
 9Dv6KU+SZnjXZizhIQNeFipgoeczShUDRNCAlyOOYXtmKnJQmSSl6KMXoiLcoYs1U0evNkJdP
 qMLMSzbumQJenGSaanOH0iePOm1x0iF4cTbjHVSchVRbr4C/HJs4JcYt+hKHZPVEh2k0n92LR
 3WXU7Sxl/LbdqVzcxOgW2B1p1+GP/uZyMcK9XkYIt7rzJjC0f1SjmUsxqAuuoYrx8uTmLcNra
 M29rx7BY0DAR/glLeqjNoEL/9wx6eABiCeCN4R0Gawz1ELC3iA7iPaivrgRiESCPnUN+XYte5
 qNJGFZC9fTvGOG/m/LvsIwyRDTw=

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 approac=
h
>> 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 firs=
t
>> 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 woul=
d
>> 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).