Received-SPF: pass (google.com: domain of linux-kernel+bounces-35412-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <223a4e75-2e06-4bc6-a70c-823f0eb308d7@gmx.de>
Date: Tue, 23 Jan 2024 14:55:27 +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>, Matthew Garrett <mjg59@srcf.ucam.org>,
 Peter Jones <pjones@redhat.com>
Cc: linux-efi@vger.kernel.org, Jeremy Kerr <jk@ozlabs.org>,
 linux-kernel@vger.kernel.org
References: <20240122231507.1307793-1-timschumi@gmx.de>
 <CAMj1kXHSSRacU3hp6D3sdUKDESi1FoD33Qi=5Df+=_biZ-vqhA@mail.gmail.com>
From: Tim Schumacher <timschumi@gmx.de>
In-Reply-To: <CAMj1kXHSSRacU3hp6D3sdUKDESi1FoD33Qi=5Df+=_biZ-vqhA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:l9QfBb6Avjk=;CVtajfVn/ov+5nD+4lYgvKjPGnI
 qlW3e0LXqNfU2rBzJ8K18xi5VxjwkW9msjUbM2P+qEx6Hm1CGfIxZ8Cj6Bq+gv7s0JTWHXS10
 oZpvA8V0PXAmfIN/TkR0eWas3GPP4VWUTGmoiGsoZHgvkEaauJwzfeboar+tdHn2OaU8qtlmO
 Z3cdCARtoD2+EdM+bfFshXtCWoM8vvueBC6Hv7iVTc0dD0eMOWWIWm1CI5s9wH8On9A8FIg8Q
 GWXNVwGIdokW/uwrHKi4/8SCt8+Yn5FmqfF0fSxmGdsOicdtETTV/PcUGehJVKSaFEjlM4ZNI
 PS6lwdKpIvEHX2363EcWfyr9Av5o/oCG4z1EY2zwIpk+HeEvqk7aImdnGDhXB0cT30Hh0WA2N
 eSWxmmmQLhkrha8ldNPkWGaYLMWsEgqz9Ip3I1D4kwMoiaglfqWNBvEBWt4/0R+5fAVrojilj
 omHO/W++Vim8N5g6OGgmImuIKcfQ1lUIvhkuf0WWDT6cZpVmuycNSf8A3C8Yd7kby+yuwMlQs
 E7+3pd19IyIqnPSlvAlbyWZhIuNUVUMGZ9gg05XgXTuWmkdI+1EYhxORT/OptMEK115Qc0m+4
 tjaG/RWcA1IFgnDgeW8oPsCwBOdZJ+n1ce5qOCw7tdMe1ks4Gu+vX+OfAYdoytn3IquOKq3HM
 9UvP1p02U3Jk1CWteLvTJpWSINAr79ikK/AeQ84KcCpHNA4vYEE99JxOXiOSqnCGhpn0sjoS+
 E2AzOcVjgL390cOgu+4OQ2nWx5WcbBAmQAN7lwOj/1siwdm67YPRZ0En4LaMDUnoHm1MJuuMP
 rEzz33ahaIQld2CmbzDgBl/Kvvrbnc8BCKJh61gumQHHh8VN5DrJA0cGl0aeMmvku1ugBT9Og
 S+zTOIoRSXjpycverfSvDomrcCfhC6H4Wgm9S8VhF8674WRnysDO2xD+94OZ7C4m99U9PLNyr
 yhfOqvLXDS5GFpwqBZO1GLNeySs=

On 23.01.24 12:24, Ard Biesheuvel wrote:
> On Tue, 23 Jan 2024 at 00:15, Tim Schumacher <timschumi@gmx.de> wrote:
>>
>> This sidesteps a quirk in a few old (2011-ish) UEFI implementations,
>> where a call to `GetNextVariableName` with a buffer size larger than 51=
2
>> bytes will always return `EFI_INVALID_PARAMETER`.
>
> I wonder if we might just reduce this to 512 and be done with it.
> Presumably, Windows boots fine in UEFI mode on these machines, which
> suggests that it passes a value <=3D 512 too, and I don't recall ever
> encountering systems using extremely long variable names (i.e., longer
> than 512 byte)

I'd rather avoid introducing deviations from the specifications on the
kernel side as well. Someone or something might legitimately set a large
variable name, so we'd have to have resize logic anyways (to resize from
512 to 512+). Also, as mentioned on the patch, I'm entirely unsure what
the size ends up being used for, so I'd rather err on the side of
caution (most importantly in regards to the buffer size).

Windows _does_ boot fine (and is able to read all the variables), so
they presumably start off with 512 or smaller. FreeBSD definitely starts
from 512, but they also implement additional resize logic.

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.