Intel engineer H. Peter Anvin proposes removing kernel configuration options for EFI stub and relocatable kernel support, arguing they are obsolete and add no runtime cost on modern x86 systems.
A new patch series from Intel's lead Linux kernel engineer H. Peter Anvin aims to fundamentally simplify the x86/x86_64 Linux kernel boot process by making two key features unconditional: EFI stub support and relocatable kernel builds. The proposal, posted for review on January 21, 2026, argues that these configurations are now obsolete and their removal will streamline kernel development without impacting runtime performance.
The core change targets the CONFIG_EFI_STUB option, which allows the compressed kernel executable to be loaded directly by the EFI firmware, bypassing traditional bootloaders like GRUB or systemd-boot. Anvin's argument rests on two practical realities of modern computing. First, the vast majority of x86 systems deployed today boot via UEFI firmware, not legacy BIOS. Second, the EFI stub imposes no runtime memory overhead; it is a boot-time mechanism only. As Anvin states in the patch series, "EFI_STUB doesn't impact or restrict" the use of standard bootloaders. Its presence simply provides an alternative, streamlined path for systems that can use it. By making it mandatory, the kernel configuration becomes simpler, and the code path is more thoroughly tested across all builds.
The second major change removes the option to build a non-relocatable kernel. A relocatable kernel can be loaded at any address in physical memory, a critical feature for modern security and flexibility. This capability is essential for Kernel Address Space Layout Randomization (KASLR), a security mitigation that randomizes the kernel's base address to make exploits harder. Anvin dismisses the notion of a non-relocatable kernel as having "absolutely no valid reason" in contemporary systems. The patch series contends that maintaining the option to build a non-relocatable kernel adds unnecessary complexity to the build system and boot code for a configuration that offers no practical advantage.
The implications of this change are primarily for kernel developers and distribution maintainers. For users, the transition should be seamless. The runtime memory footprint remains unchanged. The primary difference is that future kernel builds will inherently support direct EFI booting and address-space randomization, eliminating the need for specific configuration options. This aligns with the broader trend in the Linux kernel toward sensible defaults and removing legacy, underutilized configuration knobs that complicate the codebase.
The patch series is currently under review on the Linux kernel mailing list. If accepted, the changes will be merged into a future kernel release, likely in the 6.x series. This move represents a pragmatic cleanup of the x86 boot architecture, reflecting the industry's full embrace of UEFI and the critical importance of memory security features like KASLR.
Relevant Links:
Comments
Please log in or register to join the discussion