| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <170870627680.398.14239353324950664750.tip-bot2@tip-bot2> Date: Fri, 23 Feb 2024 16:37:56 -0000 From: "tip-bot2 for Chris Koch" <tip-bot2@...utronix.de> To: linux-tip-commits@...r.kernel.org Cc: Cloud Hsu <cloudhsu@...gle.com>, Chris Koch <chrisko@...gle.com>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin (Intel)" <hpa@...or.com>, x86@...nel.org, linux-kernel@...r.kernel.org Subject: [tip: x86/boot] kexec: Allocate kernel above bzImage's pref_address The following commit has been merged into the x86/boot branch of tip: Commit-ID: 43b1d3e68ee7f41c494ee5558d8def3d3d0b7f1b Gitweb: https://git.kernel.org/tip/43b1d3e68ee7f41c494ee5558d8def3d3d0b7f1b Author: Chris Koch <chrisko@...gle.com> AuthorDate: Fri, 15 Dec 2023 11:05:21 -08:00 Committer: Dave Hansen <dave.hansen@...ux.intel.com> CommitterDate: Thu, 22 Feb 2024 15:13:57 -08:00 kexec: Allocate kernel above bzImage's pref_address A relocatable kernel will relocate itself to pref_address if it is loaded below pref_address. This means a booted kernel may be relocating itself to an area with reserved memory on modern systems, potentially clobbering arbitrary data that may be important to the system. This is often the case, as the default value of PHYSICAL_START is 0x1000000 and kernels are typically loaded at 0x100000 or above by bootloaders like iPXE or kexec. GRUB behaves like the approach implemented here. Also fixes the documentation around pref_address and PHYSICAL_START to be accurate. [ dhansen: changelog tweak ] Co-developed-by: Cloud Hsu <cloudhsu@...gle.com> Signed-off-by: Cloud Hsu <cloudhsu@...gle.com> Signed-off-by: Chris Koch <chrisko@...gle.com> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com> Reviewed-by: H. Peter Anvin (Intel) <hpa@...or.com> Link: https://lore.kernel.org/all/20231215190521.3796022-1-chrisko%40google.com --- Documentation/arch/x86/boot.rst | 3 ++- arch/x86/Kconfig | 10 +++++----- arch/x86/kernel/kexec-bzimage64.c | 5 ++++- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst index c513855..4fd492c 100644 --- a/Documentation/arch/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -878,7 +878,8 @@ Protocol: 2.10+ address if possible. A non-relocatable kernel will unconditionally move itself and to run - at this address. + at this address. A relocatable kernel will move itself to this address if it + loaded below this address. ============ ======= Field name: init_size diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5edec17..1a33575 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2114,11 +2114,11 @@ config PHYSICAL_START help This gives the physical address where the kernel is loaded. - If kernel is a 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 and will ignore above physical - address. + 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 diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c index 2a422e0..cde167b 100644 --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/x86/kernel/kexec-bzimage64.c @@ -503,7 +503,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel, kbuf.bufsz = kernel_len - kern16_size; kbuf.memsz = PAGE_ALIGN(header->init_size); kbuf.buf_align = header->kernel_alignment; - kbuf.buf_min = MIN_KERNEL_LOAD_ADDR; + if (header->pref_address < MIN_KERNEL_LOAD_ADDR) + kbuf.buf_min = MIN_KERNEL_LOAD_ADDR; + else + kbuf.buf_min = header->pref_address; kbuf.mem = KEXEC_BUF_MEM_UNKNOWN; ret = kexec_add_buffer(&kbuf); if (ret)
Powered by blists - more mailing lists