Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Mon, 23 Oct 2023 02:31:21 +0000
Mime-Version: 1.0
Message-ID: <20231023023121.1464544-1-jsperbeck@google.com>
Subject: [PATCH] x86/kexec: set MIN_KERNEL_LOAD_ADDR to 0x01000000
From:   John Sperbeck <jsperbeck@google.com>
To:     Eric Biederman <ebiederm@xmission.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin " <hpa@zytor.com>, Baoquan He <bhe@redhat.com>,
        kexec@lists.infradead.org
Cc:     Dave Hansen <dave.hansen@linux.intel.com>,
        Zac Tang <zactang@google.com>, Cloud Hsu <cloudhsu@google.com>,
        linux-kernel@vger.kernel.org, John Sperbeck <jsperbeck@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

The physical memory range that kexec selects for the compressed
bzimage target kernel, might not be where it runs from.  The
startup_64() code in head_64.S copies itself out of the way
before the decompression so it doesn't clobber itself.

If the start of the memory range selected by kexec is above
LOAD_PHYSICAL_ADDR (0x01000000 by default), then the copy remains
within the memory area.  But if the start is below this range,
then the copy will likely end up outside the range.

Usually, this will be harmless because not much memory is in use
at the time of the pre-decompression copy, so there is little
to accidentally clobber.  However, an unlucky choice for the
adress of the kernel and the initrd could put the initrd in harm's
way.  For example:

    0x00400000 - physical address for target kernel
    0x03ff8000 - physical address of seven-page initrd
    0x0302c000 - size of uncompressed kernel (about 50 Mbytes)

The decompressed kernel will span 0x01000000 through 0x0402c000,
which will overwrite the initrd.

If the kexec code restricts itself to physical addresses above
0x01000000, then the pre-decompression copy and the decompression
itself will stay within the bounds of the memory kexec selected
(unless a non-default value is used in the target kernel for
CONFIG_PHYSICAL_START, which will change LOAD_PHYSICAL_ADDR,
but that's probably unsolvable unless the target kernel were to
somehow communicate this to kexec).

Signed-off-by: John Sperbeck <jsperbeck@google.com>
---
 arch/x86/kernel/kexec-bzimage64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index a61c12c01270..d6bf6c13dab1 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -36,7 +36,7 @@
  */
 #define MIN_PURGATORY_ADDR	0x3000
 #define MIN_BOOTPARAM_ADDR	0x3000
-#define MIN_KERNEL_LOAD_ADDR	0x100000
+#define MIN_KERNEL_LOAD_ADDR	0x1000000
 #define MIN_INITRD_LOAD_ADDR	0x1000000
 
 /*
-- 
2.42.0.655.g421f12c284-goog