On 10/01/2014 06:52 AM, Vivek Goyal wrote: > > Hi Peter, > > I think there is some confusion. I will try to clarify. > > If we have 32bit signed overflow, we will not have a functional kernel. > And that's the message we get when we try to kexec with > CONFIG_RANDOMIZE_BASE=y. > And how does that happen? > ********************************************************************** > [ 340.709078] kexec: Starting new kernel > early console in decompress_kernel > KASLR disabled by default... > > Decompressing Linux... Parsing ELF... > > Performing relocations... > 32-bit relocation outside of kernel! > > > -- System halted > ***************************************************************** > > We realized that kexec tries to load kernel at higher physical addresses > and that can lead to problmes. > > Currently for x86_64, handle_relocations() will perform relocations if > kernel is not loaded at LOAD_PHYSICAL_ADDR. I think this does not work for > all the cases and kerenl can not be loaded anywhere in the physical address > space. And that's why we run into issues with kexec. > > My understanding is that we introduce handle_relcoations() i386 style > because of RANDOMIZE_BASE. If that's the case, one possible solution > is that perform relocations only if ranodmize base logic has chosen > a different load location for kernel than where boot loader loaded > it. Otherwise don't do anything. > > In case of kexec/kdump, we will pass "nokaslr" to second kernel forcing > it to do nothing and let the kernel run where it was loaded by bootloader. > And in that case handle_relocations() should not do any relocations and > that should allow kernel to be loaded anywhere in physical memory on > x86_64. > Sorry... this makes no sense. For x86-64, there is no direct connection between the physical and virtual address spaces that the kernel runs in... -hpa
