On October 22, 2023 7:31:21 PM PDT, John Sperbeck <jsperbeck@xxxxxxxxxx> 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@xxxxxxxxxx> >--- > 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. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
