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] [day] [month] [year] [list]

Message-ID: <36C4A641-A124-4082-884D-90AE22B10275@zytor.com>
Date: Mon, 26 Jan 2026 19:21:47 -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 7:14:27 PM PST, Simon Glass <sjg@...omium.org> wrote:
>Hi Peter,
>
>On Tue, 27 Jan 2026 at 15:55, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> 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
>
>(joining the threads)
>
>> Bypassing the firmware stub (BIOS or EFI) is really only appropriate for special user cases, like kexec, because it removes the ability for the kernel to deal with system issues at an early point.
>
>Does this dealing happen in the EFI stub, or later? Are you referring
>to ACPI fix-ups or something else?
>
>>
>> However, kexec needs it, and it's not going to go away. However, that doesn't mean we should encourage this in cases which doesn't need it (no matter what the Grub maintainers tell you.)
>>
>> Now, if you are using KVM without EFI you are probably doing BIOS boot (regardless of if you know it or not), entering via the BIOS firmware stub.
>
>I am thinking of the 64-bit entry point to the kernel. everything
>being laid out in memory ready to go.
>
>>
>> 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.
>
>More generally I am thinking about a simple and clean API for the
>kernel that doesn't involve having to provide 30K lines of firmware
>code just to boot. The BIOS entry point (if that is what it is called)
>is quite close to this ideal, even though I know it has shortcomings.
>
>Regards,
>Simon

Yes, I understand. 

The 32/64-bit entrypoints aren't going away; it would be impossible to do so. 

The general rule is: do things as late in the boot process as possible, but no later.