Re: [RFC PATCH 0/5] x86/boot: Allow to perform randomization for uncompressed kernel image

["H. Peter Anvin" <hpa@zytor.com>]

On January 26, 2026 5:33:50 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
>Hi all,
>
>This RFC patch series introduces relocatable uncompressed kernel image,
>which is allowed to perform kerenl image virtual address randomization
>in 64-bit booting entry instead of decompression phase.
>
>- Background
>
>Currently, kernel image virtual address randomization is only performed
>during the decompression phase. However, in certain scenarios, such as
>secure container environments (e.g., Kata Containers), to speed up the
>boot process, the system may boot directly from an uncompressed kernel
>image. In such cases, virtual address randomization cannot be executed.
>Although the security enhancement provided by KASLR is limited, there is
>still a potential demand to allow uncompressed kernel images to perform
>virtual address randomization (for example, future support for x86 PIE).
>
>- Approaches
>
>Currently, the x86 kernel uses static compilation, but it retains
>relocation information through the '--emit-relocs' option, which is then
>simplified into a relocation table using 'relocs' tool. To enable
>virtual address randomization for uncompressed kernel images, relocation
>information is required, and there are several possible approaches:
>
>1) Who will perform the randomization:
>
>VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
>randomization. This would require additional modifications to the VMM,
>and vmlinux.relocs needs to be packaged when shipping.
>
>Kernel: The kernel performs randomization itself at the kernel
>entry point, requiring no modifications to the VMM.
>
>2) relocation information format:
>
>vmlinux.relocs: It only contains the necessary relocation entries and is
>simplified, making it small enough. However, it is a format defined
>within the kernel that was previously used only internally and is not
>part of the ABI.
>
>rela.* sections: It is the standard ELF ABI, but
>it contains RIP-relative relocation entries, which are more common in
>kernel, causing the kernel image to be larger.
>
>- Implementation
>
>The final implementation of this plan extends the 'relocs' tool to allow
>the insertion of relocation information into a reserved section of the
>kernel (referencing the MIPS implementation). This enables the reading
>of that information and subsequent execution of relocations when booting
>directly from an uncompressed kernel. Currently, this implementation is
>only available for 64-bit and has been tested with both PVH entry
>booting and standard 64-bit Linux entry. And the default reserve size is
>1MB for now, which is enough for defconfig.
>
>- TODO
>
>Clean up the decompression KASLR code to allow it to be shared with the
>booting phase.
>
>
>Thanks!
>
>Hou Wenlong (5):
>  x86/relocs: Cleanup cmdline options
>  x86/relocs: Insert relocations into input file
>  x86: Allow to build relocatable uncompressed kernel binary
>  x86/boot: Perform virtual address relocation in kernel entry
>  x86/boot: Use '.data.relocs' section for performing relocations during
>    decompression
>
> arch/x86/Kconfig                  |  20 ++++++
> arch/x86/Makefile.postlink        |  33 +++++++++
> arch/x86/boot/compressed/Makefile |   6 +-
> arch/x86/boot/compressed/misc.c   |   8 +++
> arch/x86/boot/startup/Makefile    |   1 +
> arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
> arch/x86/include/asm/setup.h      |   1 +
> arch/x86/kernel/head_64.S         |   7 ++
> arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
> arch/x86/lib/cmdline.c            |   6 ++
> arch/x86/lib/kaslr.c              |   5 ++
> arch/x86/platform/pvh/head.S      |  15 +++-
> arch/x86/tools/relocs.c           |  64 ++++++++++++++---
> arch/x86/tools/relocs.h           |  15 ++--
> arch/x86/tools/relocs_common.c    |  24 ++++---
> 15 files changed, 309 insertions(+), 32 deletions(-)
> create mode 100644 arch/x86/Makefile.postlink
> create mode 100644 arch/x86/boot/startup/kaslr.c
>
>--
>2.31.1
>

Hi!

At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. 

Thanks!