From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AFB4221DAD for ; Mon, 26 Jan 2026 19:31:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769455904; cv=none; b=p5YUyaOzKkc5ny8Zbswkkpleegx5he1lvQtSdsK0Aqr6WMzAXsN9yuRQcLhPJ7QXfacty5Kmox54b5KYqXRPssgyc2a5JqwN5k+cRD2Hfe0+EOvPLaoZB32LbYqX5UnrVFe0qT1QPRVe8ZedNuSuVts4je/8WFT6JT3wy3mIqLc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769455904; c=relaxed/simple; bh=lCp47es90L5KLLLJutZPBztLVIAZXjT4mH5Bd4LgEXs=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=SYWCCCUTKaUgLzdbWR4uVIajD+IT8kJMLKJZXrppak9R93dqbzCbYQepk1SYMyD+GcRxU8oN6pzJe4QiKBnuj48fbEoQbAdPBI/k9BT7/5m2wfIIvFRa9iGuBBBkmtJ5YqYDAbhuAGG8O9mH2QXeqh6PifWnsfUEX0Gv2m26O2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=YqYTbZVJ; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="YqYTbZVJ" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 60QJUX0M3230378 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 26 Jan 2026 11:30:34 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 60QJUX0M3230378 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1769455836; bh=F8FFTbCNA0IjhSYw8p1wkH57XCUpK2L9SYc1+fWEBrQ=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=YqYTbZVJKC/Aw/m2Br3dv5p78b8CchhKHUqaJmxvV9P1lEj6jc6Qw3uSR8WFDmhSl gL98Fl8W2D/XHGdNGF5RyFUOtIdjWU5SAwNTbmi+JzElQeIb6xEayZNU6xYYoxFNbu WaGILQBpkwzRKeveYmOiEB3aBLnZQ2KvKijhAWTZIS+L9PnqmUm5eZrcce50ik3rp8 FbnKe9k3RY3h55u6l3zwOB+S6Ql3WYZeJEV4E9XYFTGlafTCPnFA8xJIPDnmE5bgB3 fM1OI2FeLoO9sVAtoi4qvcU5WLb/fRDW3qpJRKFGMWOsoTsvgRYmO8DUEltOB5Cag8 uMMTU4u5/7+SA== Date: Mon, 26 Jan 2026 11:30:28 -0800 From: "H. Peter Anvin" To: Hou Wenlong , linux-kernel@vger.kernel.org CC: Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , =?ISO-8859-1?Q?Thomas_Wei=DFschuh?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= , xen-devel@lists.xenproject.org Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_0/5=5D_x86/boot=3A_Allow_to_perfor?= =?US-ASCII?Q?m_randomization_for_uncompressed_kernel_image?= User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 26, 2026 5:33:50 AM PST, Hou Wenlong 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=2E > >- Background > >Currently, kernel image virtual address randomization is only performed >during the decompression phase=2E However, in certain scenarios, such as >secure container environments (e=2Eg=2E, Kata Containers), to speed up th= e >boot process, the system may boot directly from an uncompressed kernel >image=2E In such cases, virtual address randomization cannot be executed= =2E >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)= =2E > >- 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=2E 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=2Erelocs after loading vmlinux to perform >randomization=2E This would require additional modifications to the VMM, >and vmlinux=2Erelocs needs to be packaged when shipping=2E > >Kernel: The kernel performs randomization itself at the kernel >entry point, requiring no modifications to the VMM=2E > >2) relocation information format: > >vmlinux=2Erelocs: It only contains the necessary relocation entries and i= s >simplified, making it small enough=2E However, it is a format defined >within the kernel that was previously used only internally and is not >part of the ABI=2E > >rela=2E* 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=2E > >- 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)=2E This enables the reading >of that information and subsequent execution of relocations when booting >directly from an uncompressed kernel=2E Currently, this implementation is >only available for 64-bit and has been tested with both PVH entry >booting and standard 64-bit Linux entry=2E And the default reserve size i= s >1MB for now, which is enough for defconfig=2E > >- TODO > >Clean up the decompression KASLR code to allow it to be shared with the >booting phase=2E > > >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 '=2Edata=2Erelocs' section for performing relocations dur= ing > decompression > > arch/x86/Kconfig | 20 ++++++ > arch/x86/Makefile=2Epostlink | 33 +++++++++ > arch/x86/boot/compressed/Makefile | 6 +- > arch/x86/boot/compressed/misc=2Ec | 8 +++ > arch/x86/boot/startup/Makefile | 1 + > arch/x86/boot/startup/kaslr=2Ec | 116 ++++++++++++++++++++++++++++++ > arch/x86/include/asm/setup=2Eh | 1 + > arch/x86/kernel/head_64=2ES | 7 ++ > arch/x86/kernel/vmlinux=2Elds=2ES | 20 ++++++ > arch/x86/lib/cmdline=2Ec | 6 ++ > arch/x86/lib/kaslr=2Ec | 5 ++ > arch/x86/platform/pvh/head=2ES | 15 +++- > arch/x86/tools/relocs=2Ec | 64 ++++++++++++++--- > arch/x86/tools/relocs=2Eh | 15 ++-- > arch/x86/tools/relocs_common=2Ec | 24 ++++--- > 15 files changed, 309 insertions(+), 32 deletions(-) > create mode 100644 arch/x86/Makefile=2Epostlink > create mode 100644 arch/x86/boot/startup/kaslr=2Ec > >-- >2=2E31=2E1 > 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 p= erhaps have any measurements to show how much improvement we are talking ab= out? That would be really useful=2E=20 Thanks!=20