From: "H. Peter Anvin" <hpa@zytor.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Uros Bizjak <ubizjak@gmail.com>, Petr Mladek <pmladek@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <kees@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Nathan Chancellor <nathan@kernel.org>,
Kiryl Shutsemau <kas@kernel.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
x86@kernel.org
Subject: [PATCH v1 09/14] x86/boot: make the relocatable kernel unconditional
Date: Tue, 20 Jan 2026 11:54:01 -0800 [thread overview]
Message-ID: <20260120195407.1163051-10-hpa@zytor.com> (raw)
In-Reply-To: <20260120195407.1163051-1-hpa@zytor.com>
There is absolutely no valid reason to build a non-relocatable kernel
anymore. It has no effect on the runtime memory footprint since it is
handled entirely in preboot code. Futhermore, the relocatable kernel
is required for EFI stub support.
Remove CONFIG_RELOCATABLE and make the non-relocatable kernel
unconditional.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
arch/x86/Kconfig | 71 ++++--------------------------
arch/x86/boot/compressed/head_32.S | 2 -
arch/x86/boot/compressed/head_64.S | 4 --
arch/x86/boot/compressed/misc.c | 8 ----
| 12 +----
5 files changed, 11 insertions(+), 86 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 14e2b00a3815..a0fe0349fb77 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2018,61 +2018,16 @@ config PHYSICAL_START
help
This gives the physical address where the kernel is loaded.
- If the kernel is not relocatable (CONFIG_RELOCATABLE=n) then bzImage
- will decompress itself to above physical address and run from there.
- Otherwise, bzImage will run from the address where it has been loaded
- by the boot loader. The only exception is if it is loaded below the
- above physical address, in which case it will relocate itself there.
-
- In normal kdump cases one does not have to set/change this option
- as now bzImage can be compiled as a completely relocatable image
- (CONFIG_RELOCATABLE=y) and be used to load and run from a different
- address. This option is mainly useful for the folks who don't want
- to use a bzImage for capturing the crash dump and want to use a
- vmlinux instead. vmlinux is not relocatable hence a kernel needs
- to be specifically compiled to run from a specific memory area
- (normally a reserved region) and this option comes handy.
-
- So if you are using bzImage for capturing the crash dump,
- leave the value here unchanged to 0x1000000 and set
- CONFIG_RELOCATABLE=y. Otherwise if you plan to use vmlinux
- for capturing the crash dump change this value to start of
- the reserved region. In other words, it can be set based on
- the "X" value as specified in the "crashkernel=YM@XM"
- command line boot parameter passed to the panic-ed
- kernel. Please take a look at Documentation/admin-guide/kdump/kdump.rst
- for more details about crash dumps.
-
- Usage of bzImage for capturing the crash dump is recommended as
- one does not have to build two kernels. Same kernel can be used
- as production kernel and capture kernel. Above option should have
- gone away after relocatable bzImage support is introduced. But it
- is present because there are users out there who continue to use
- vmlinux for dump capture. This option should go away down the
- line.
+ If the kernel is loaded at a physical address below this address
+ by the boot loader it will relocate itself there.
- Don't change this unless you know what you are doing.
+ The addresses in the vmlinux and System.map files are based
+ at this address.
-config RELOCATABLE
- bool "Build a relocatable kernel"
- default y
- help
- This builds a kernel image that retains relocation information
- so it can be loaded someplace besides the default 1MB.
- The relocations tend to make the kernel binary about 10% larger,
- but are discarded at runtime.
-
- One use is for the kexec on panic case where the recovery kernel
- must live at a different physical address than the primary
- kernel.
-
- Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
- it has been loaded at and the compile time physical address
- (CONFIG_PHYSICAL_START) is used as the minimum location.
+ Don't change this unless you know what you are doing.
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image (KASLR)"
- depends on RELOCATABLE
default y
help
In support of Kernel Address Space Layout Randomization (KASLR),
@@ -2108,7 +2063,7 @@ config RANDOMIZE_BASE
# Relocation on x86 needs some additional build support
config X86_NEED_RELOCS
def_bool y
- depends on RANDOMIZE_BASE || (X86_32 && RELOCATABLE)
+ depends on RANDOMIZE_BASE || X86_32
select ARCH_VMLINUX_NEEDS_RELOCS
config PHYSICAL_ALIGN
@@ -2121,17 +2076,9 @@ config PHYSICAL_ALIGN
where kernel is loaded and run from. Kernel is compiled for an
address which meets above alignment restriction.
- If bootloader loads the kernel at a non-aligned address and
- CONFIG_RELOCATABLE is set, kernel will move itself to nearest
- address aligned to above value and run from there.
-
- If bootloader loads the kernel at a non-aligned address and
- CONFIG_RELOCATABLE is not set, kernel will ignore the run time
- load address and decompress itself to the address it has been
- compiled for and run from there. The address for which kernel is
- compiled already meets above alignment restrictions. Hence the
- end result is that kernel runs from a physical address meeting
- above alignment restrictions.
+ If bootloader loads the kernel at a non-aligned address the
+ kernel will move itself upwards to the nearest address
+ aligned to above value and run from there.
On 32-bit this value must be a multiple of 0x2000. On 64-bit
this value must be a multiple of 0x200000.
diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index 1cfe9802a42f..79d9e2c330ba 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -82,7 +82,6 @@ SYM_FUNC_START(startup_32)
* %ebp is calculated to be the address that the kernel will be decompressed to.
*/
-#ifdef CONFIG_RELOCATABLE
leal startup_32@GOTOFF(%edx), %ebx
movl BP_kernel_alignment(%esi), %eax
decl %eax
@@ -91,7 +90,6 @@ SYM_FUNC_START(startup_32)
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
jae 1f
-#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index d9dab940ff62..8a964a4d45c2 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -143,7 +143,6 @@ SYM_FUNC_START(startup_32)
* for safe in-place decompression.
*/
-#ifdef CONFIG_RELOCATABLE
movl %ebp, %ebx
movl BP_kernel_alignment(%esi), %eax
decl %eax
@@ -152,7 +151,6 @@ SYM_FUNC_START(startup_32)
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
jae 1f
-#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
@@ -312,7 +310,6 @@ SYM_CODE_START(startup_64)
*/
/* Start with the delta to where the kernel will run at. */
-#ifdef CONFIG_RELOCATABLE
leaq startup_32(%rip) /* - $startup_32 */, %rbp
movl BP_kernel_alignment(%rsi), %eax
decl %eax
@@ -321,7 +318,6 @@ SYM_CODE_START(startup_64)
andq %rax, %rbp
cmpq $LOAD_PHYSICAL_ADDR, %rbp
jae 1f
-#endif
movq $LOAD_PHYSICAL_ADDR, %rbp
1:
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 0f41ca0e52c0..0cdc164286fc 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -314,12 +314,8 @@ static size_t parse_elf(void *output)
if ((phdr->p_align % 0x200000) != 0)
error("Alignment of LOAD segment isn't multiple of 2MB");
#endif
-#ifdef CONFIG_RELOCATABLE
dest = output;
dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);
-#else
- dest = (void *)(phdr->p_paddr);
-#endif
memmove(dest, output + phdr->p_offset, phdr->p_filesz);
break;
default: /* Ignore other PT_* */ break;
@@ -506,10 +502,6 @@ asmlinkage __visible void *extract_kernel(void *rmode, unsigned char *output)
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
#endif
-#ifndef CONFIG_RELOCATABLE
- if (virt_addr != LOAD_PHYSICAL_ADDR)
- error("Destination virtual address changed when not relocatable");
-#endif
debug_putstr("\nDecompressing Linux... ");
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 776bd0631bce..2828b25707bb 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -334,24 +334,16 @@ initrd_addr_max: .long 0x7fffffff
kernel_alignment: .long CONFIG_PHYSICAL_ALIGN #physical addr alignment
#required for protected mode
#kernel
-#ifdef CONFIG_RELOCATABLE
-relocatable_kernel: .byte 1
-#else
-relocatable_kernel: .byte 0
-#endif
+relocatable_kernel: .byte 1 # Always relocatable
min_alignment: .byte MIN_KERNEL_ALIGN_LG2 # minimum alignment
xloadflags:
#ifdef CONFIG_X86_64
# define XLF0 XLF_KERNEL_64 /* 64-bit kernel */
-#else
-# define XLF0 0
-#endif
-
-#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64)
/* kernel/boot_param/ramdisk could be loaded above 4g */
# define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
#else
+# define XLF0 0
# define XLF1 0
#endif
--
2.52.0
next prev parent reply other threads:[~2026-01-20 19:55 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260119192923.651588-1-hpa@zytor.com>
2026-01-20 19:53 ` [PATCH v1 00/14] x86 boot code cleanups, batch 1 H. Peter Anvin
2026-01-20 19:53 ` [PATCH v1 01/14] x86/realmode: remove I/O port paravirtualization H. Peter Anvin
2026-01-20 21:47 ` David Laight
2026-01-21 12:27 ` Kiryl Shutsemau
2026-01-28 17:01 ` Borislav Petkov
2026-01-20 19:53 ` [PATCH v1 02/14] x86/realmode: make %gs == 0 an invariant H. Peter Anvin
2026-01-20 22:40 ` David Laight
2026-01-20 22:51 ` H. Peter Anvin
2026-01-21 0:47 ` H. Peter Anvin
2026-01-21 10:03 ` Uros Bizjak
2026-01-20 19:53 ` [PATCH v1 03/14] x86/boot: use <linux/compiler.h> H. Peter Anvin
2026-01-21 10:04 ` Uros Bizjak
2026-01-20 19:53 ` [PATCH v1 04/14] x86/boot: modernize the segment structure for the header and setup H. Peter Anvin
2026-01-20 19:53 ` [PATCH v1 05/14] x86/boot: call puts() from within die() H. Peter Anvin
2026-01-21 10:07 ` Uros Bizjak
2026-01-20 19:53 ` [PATCH v1 06/14] x86/boot: add comment barriers for the different headers H. Peter Anvin
2026-01-20 19:53 ` [PATCH v1 07/14] x86/boot: factor out the 16-bit startup code from header.S H. Peter Anvin
2026-01-21 10:08 ` Uros Bizjak
2026-01-20 19:54 ` [PATCH v1 08/14] x86: make CONFIG_EFI_STUB unconditional H. Peter Anvin
2026-01-20 19:54 ` H. Peter Anvin [this message]
2026-01-20 19:54 ` [PATCH v1 10/14] x86/boot: explicitly put the old command line pointer in header.S H. Peter Anvin
2026-01-20 19:54 ` [PATCH v1 11/14] x86/boot: use __seg_fs and __seg_gs in the real-mode boot code H. Peter Anvin
2026-01-21 8:56 ` Uros Bizjak
2026-01-21 9:40 ` Uros Bizjak
2026-01-21 15:13 ` H. Peter Anvin
2026-01-21 16:03 ` Uros Bizjak
2026-01-22 18:57 ` [PATCH v1 08/14] x86: make CONFIG_EFI_STUB unconditional Simon Glass
2026-01-23 0:11 ` H. Peter Anvin
2026-01-26 21:19 ` Simon Glass
2026-01-26 22:20 ` H. Peter Anvin
2026-01-27 1:44 ` Simon Glass
2026-01-27 2:39 ` H. Peter Anvin
2026-01-27 2:54 ` H. Peter Anvin
2026-01-27 3:14 ` Simon Glass
2026-01-27 3:21 ` H. Peter Anvin
2026-01-29 22:13 ` Simon Glass
2026-01-29 22:22 ` H. Peter Anvin
2026-01-21 16:07 ` [PATCH v1 11/14] x86/boot: use __seg_fs and __seg_gs in the real-mode boot code Uros Bizjak
2026-01-20 19:54 ` [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation H. Peter Anvin
2026-01-21 10:10 ` Uros Bizjak
2026-01-21 11:49 ` David Laight
2026-01-24 3:00 ` Maciej W. Rozycki
2026-01-24 4:24 ` H. Peter Anvin
2026-01-24 23:07 ` David Laight
2026-01-24 23:16 ` H. Peter Anvin
2026-01-24 23:40 ` H. Peter Anvin
2026-01-20 19:54 ` [PATCH v1 13/14] x86/boot: simplify x86/boot/cmdline.c by using __seg_fs H. Peter Anvin
2026-01-21 10:11 ` Uros Bizjak
2026-01-20 19:54 ` [PATCH v1 14/14] compiler-gcc: Remove obsolete RELOC_HIDE() macro H. Peter Anvin
2026-01-21 10:18 ` [PATCH v1 00/14] x86 boot code cleanups, batch 1 Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260120195407.1163051-10-hpa@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@kernel.org \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®