Message-ID: <20260128085941.GA68023@k08j02272.eu95sqa>
Date: Wed, 28 Jan 2026 16:59:41 +0800
From: Hou Wenlong <houwenlong.hwl@...group.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org,
	Lai Jiangshan <jiangshan.ljs@...group.com>,
	Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	Juergen Gross <jgross@...e.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Thomas Wei�schuh <linux@...ssschuh.net>,
	Brian Gerst <brgerst@...il.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Graf <graf@...zon.com>,
	Joel Granados <joel.granados@...nel.org>,
	Thomas Huth <thuth@...hat.com>, Uros Bizjak <ubizjak@...il.com>,
	Kiryl Shutsemau <kas@...nel.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	Guenter Roeck <linux@...ck-us.net>,
	"Xin Li (Intel)" <xin@...or.com>,
	Ilpo J�rvinen <ilpo.jarvinen@...ux.intel.com>,
	xen-devel@...ts.xenproject.org
Subject: Re: [RFC PATCH 0/5] x86/boot: Allow to perform randomization for
 uncompressed kernel image

On Tue, Jan 27, 2026 at 07:43:14AM -0800, H. Peter Anvin wrote:
> On January 27, 2026 4:03:07 AM PST, Hou Wenlong <houwenlong.hwl@...group.com> 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 <houwenlong.hwl@...group.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. 
> >>
> > 
> >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.

Maybe my expression is not clear. :(
Let me reorganize my thoughts. If you want to enable KASLR for the
guest, this patch makes booting faster, as the guest is now booting from
vmlinux instead of bzImage. However, if you don’t need KASLR for the
guest, you can continue booting from vmlinux, so the newly added
relocation process may introduce a slight overhead (due to command line
parsing), which is what I meant when I said it slows down the booting
from vmlinux. I'm not sure if you need KASLR in your case.

Thanks!

Powered by blists - more mailing lists