Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Sun, 22 Oct 2023 19:41:54 -0700
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     John Sperbeck <jsperbeck@google.com>,
        Eric Biederman <ebiederm@xmission.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        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
Subject: Re: [PATCH] x86/kexec: set MIN_KERNEL_LOAD_ADDR to 0x01000000
User-Agent: K-9 Mail for Android
In-Reply-To: <20231023023121.1464544-1-jsperbeck@google.com>
References: <20231023023121.1464544-1-jsperbeck@google.com>
Message-ID: <4FDF6E7A-C6E2-415D-A82B-342DAE6BD561@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On October 22, 2023 7:31:21 PM PDT, John Sperbeck <jsperbeck@google=2Ecom> =
wrote:
>The physical memory range that kexec selects for the compressed
>bzimage target kernel, might not be where it runs from=2E  The
>startup_64() code in head_64=2ES copies itself out of the way
>before the decompression so it doesn't clobber itself=2E
>
>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=2E  But if the start is below this range,
>then the copy will likely end up outside the range=2E
>
>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=2E  However, an unlucky choice for the
>adress of the kernel and the initrd could put the initrd in harm's
>way=2E  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=2E
>
>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)=2E
>
>Signed-off-by: John Sperbeck <jsperbeck@google=2Ecom>
>---
> arch/x86/kernel/kexec-bzimage64=2Ec | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/kernel/kexec-bzimage64=2Ec b/arch/x86/kernel/kexec-=
bzimage64=2Ec
>index a61c12c01270=2E=2Ed6bf6c13dab1 100644
>--- a/arch/x86/kernel/kexec-bzimage64=2Ec
>+++ b/arch/x86/kernel/kexec-bzimage64=2Ec
>@@ -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
>=20
> /*

This doesn't make any sense to me=2E There is already a high water mark fo=
r his much memory the kernel needs until an initrd or setup_data item can a=
ppear=2E This is just a hack, please fix it properly=2E