From: "H. Peter Anvin" <hpa@zytor.com>
To: Chris Koch <chrisko@google.com>, Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-doc@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Cc: Cloud Hsu <cloudhsu@google.com>
Subject: Re: [PATCH] kexec: allocate kernel above bzImage's pref_address
Date: Fri, 15 Dec 2023 11:31:38 -0800 [thread overview]
Message-ID: <36486D80-D0AE-4594-B337-71B3A84FC3DD@zytor.com> (raw)
In-Reply-To: <20231215190521.3796022-1-chrisko@google.com>
On December 15, 2023 11:05:21 AM PST, Chris Koch <chrisko@google.com> wrote:
>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 this patch does.
>
>Also fixes the documentation around pref_address and PHYSICAL_START to
>be accurate.
>
>Co-developed-by: Cloud Hsu <cloudhsu@google.com>
>Signed-off-by: Cloud Hsu <cloudhsu@google.com>
>Signed-off-by: Chris Koch <chrisko@google.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 22cc7a040dae..49bea8986620 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 3762f41bb092..1370f43328d7 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2109,11 +2109,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 a61c12c01270..5dcd232d58bf 100644
>--- a/arch/x86/kernel/kexec-bzimage64.c
>+++ b/arch/x86/kernel/kexec-bzimage64.c
>@@ -498,7 +498,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)
Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
next prev parent reply other threads:[~2023-12-15 19:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 19:05 [PATCH] kexec: allocate kernel above bzImage's pref_address Chris Koch
2023-12-15 19:31 ` H. Peter Anvin [this message]
2023-12-15 21:17 ` Dave Hansen
2023-12-15 21:38 ` Chris Koch
2023-12-15 22:05 ` Dave Hansen
2023-12-15 23:08 ` H. Peter Anvin
2023-12-15 23:11 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36486D80-D0AE-4594-B337-71B3A84FC3DD@zytor.com \
--to=hpa@zytor.com \
--cc=bp@alien8.de \
--cc=chrisko@google.com \
--cc=cloudhsu@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox