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: <E15F74BD-E33C-4184-B694-C152696C4895@zytor.com>
Date: Mon, 26 Jan 2026 18:54:58 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Simon Glass <sjg@...omium.org>
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

On January 26, 2026 5:44:43 PM PST, Simon Glass <sjg@...omium.org> wrote:
>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

I just realized you are the U-boot maintainer, so I'm assuming you are thinking of the case where there is no UEFI or BIOS firmware. In that case, just like as for kexec, the current entry point will continue to work, of course. 

What we don't want is having to suffer being on a BIOS or EFI system but not being able to leverage it for the benefit of the kernel. The kernel image is much easier to upgrade.