linux-kernel - Re: [PATCH v1 08/14] x86: make CONFIG_EFI

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: <CAFLszTjhJkfBrG-QiF6cEz-K1ODHPziJDsTthBUsqoZ=hDxsjA@mail.gmail.com>
Date: Tue, 27 Jan 2026 14:44:43 +1300
From: Simon Glass <sjg@...omium.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: ubizjak@...il.com, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, 
	bp@...en8.de, dave.hansen@...ux.intel.com, kas@...nel.org, kees@...nel.org, 
	linux-coco@...ts.linux.dev, mingo@...hat.com, nathan@...nel.org, 
	peterz@...radead.org, pmladek@...e.com, rick.p.edgecombe@...el.com, 
	tglx@...nel.org, x86@...nel.org
Subject: Re: [PATCH v1 08/14] x86: make CONFIG_EFI_STUB unconditional

Hi Peter,

On Tue, 27 Jan 2026 at 11:21, H. Peter Anvin <hpa@...or.com> wrote:
>
> On 2026-01-26 13:19, Simon Glass wrote:
> >>
> >> Including the EFI stub doesn't mean using EFI to boot is required.
> >
> > Yes, understood, but it adds bloat. More importantly it will lead to
> > people assuming that the stub is always used and thus unwittingly blur
> > the boundary between the stub and the kernel itself.
> >
> > What is the actual need for this?
> >
>
> I would argue that the opposite is more likely: someone inadvertently builds a
> kernel without the stub, the bootloader goes down a legacy support path and
> things seems to work... except for some platform subtleties.
>
> The bloat is there, but it is small and is only in the on-disk kernel image;
> it is zero at runtime.
>
> As such, I don't think this option is a particularly good idea anymore. If
> necessary, it could be hidden behind an EXPERT option, but I first wanted to
> see who if anyone actually cares in a meaningful way to maintain this option.
> Every option, after all, adds maintenance burden.
>
> Note that the BIOS stub is unconditionally compiled and included, and that has
> not been an issue.

What is the maintenance burden here? I could potentially take that on,
but I would first want to understand what is involved.

The use of the word 'legacy' worries me too. Is this patch a step
towards removing the non-EFI path?

Regards,
Simon