linux-kernel - Re: [PATCH] efivarfs: Iterate variables with increasing name buffer sizes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXG1Fkpy2UDFAuGr9czTCft6N-tUQ0CTOvysqW5mX_xMTQ@mail.gmail.com>
Date: Thu, 25 Jan 2024 09:12:33 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Peter Jones <pjones@...hat.com>
Cc: Tim Schumacher <timschumi@....de>, Matthew Garrett <mjg59@...f.ucam.org>, linux-efi@...r.kernel.org, 
	Jeremy Kerr <jk@...abs.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] efivarfs: Iterate variables with increasing name buffer sizes

On Wed, 24 Jan 2024 at 22:25, Peter Jones <pjones@...hat.com> wrote:
>
> On Tue, Jan 23, 2024 at 12:33 PM Tim Schumacher <timschumi@....de> wrote:
> >
> > On 23.01.24 15:09, Ard Biesheuvel wrote:
> > > On Tue, 23 Jan 2024 at 14:55, Tim Schumacher <timschumi@....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.
>

Also, the comment (and similar ones I've seen in the past) seem to
refer to the entire variable (name + payload) rather than just the
name.

So I am still leaning towards simply reducing this to 512 bytes.