Re: [PATCH] x86/kexec: set MIN_KERNEL_LOAD_ADDR to 0x01000000

["H. Peter Anvin" <hpa@zytor.com>]

On October 22, 2023 7:31:21 PM PDT, John Sperbeck <jsperbeck@google.com> wrote:
>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
> 
> /*

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