On January 27, 2026 4:03:07 AM PST, Hou Wenlong <[email protected]> wrote: >On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote: >> On January 26, 2026 5:33:50 AM PST, Hou Wenlong >> <[email protected]> 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. >> > >Hi! > >Uh, sorry that it may not meet your needs. In fact, it will slow down >when booting directly from an uncompressed kernel. The improvement >described in the patchset compares booting directly from vmlinux versus >booting from bzImage when we want to enable KASLR for guests in MicroVM >scenarios. There is a similar idea in [0], where KASLR randomization is >implemented on the VMM side. Now we want to implement it directly in the >guest kernel to reduce modifications to the VMMs. There are some >measurements in [0]; however, the comparison is between vmlinux and >bzImage. > >In my test environment, compared to the original direct kernel booting, >it would add 2ms for my test configuration [1] based on the Kata >Containers repository due to the self-relocation phase. Booting from >bzImage does not affect the boot time, as it simply inserts >'vmlinux.relocs' into vmlinux, resulting in no change to the total size. >The decompression time should also not be affected; I didn't notice any >difference when measuring the decompression(). > >[0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578 >[1]: >https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config > >Thanks! > >> Thanks!
Didn't you say that that was the reason for this? I'm confused now.
