Kexec failing in handle_relocations() (Was: Re: kexec fails to boot kernels where CONFIG_RANDOMIZE_BASE=y is set)

[Vivek Goyal]

On Thu, Aug 21, 2014 at 09:27:17PM +0200, Thomas D. wrote:
> Hi,
> 
> Vivek Goyal wrote:
> > Thomas, can you please test kexec with "nokaslr" specified in command
> > line. This can atleast get you going for now till the problem is actually
> > fixed.
> 
> I booted linux-3.15.10 with "nokaslr"
> 
> >  # dmesg | grep -i command
> > [    0.000000] Command line: BOOT_IMAGE=/kernel dolvm video=1280x1024 root=UUID=6d42... rootfs=ext4 nokaslr initrd=/initramfs
> > [    0.000000] Kernel command line: BOOT_IMAGE=/kernel dolvm video=1280x1024 root=UUID=6d42... rootfs=ext4 nokaslr initrd=/initramfs
> 
> and run kexec with
> 
> > --reuse-cmdline -l /boot/kernel root=/dev/dm-3  --initrd=/boot/initramfs
> 
> But it still doesn't reboot. I see no difference between using "nokaslr"
> or not.

[ CC hpa ]

I think handle_relocations() is contributing to the problem here.

I enabled earlyprintk and enabled debug boot messages. I also put some
debug messages of my own to print values of some variables and I see
following when I try to kexec.

**********************************************************************
[  340.709078] kexec: Starting new kernel
early console in decompress_kernel
KASLR disabled by default...

Decompressing Linux... Parsing ELF...

min_addr=000000042e000000
delta=000000042d000000
Performing relocations...
map=00000004ad000000

32-bit relocation outside of kernel!


 -- System halted
*****************************************************************

So min_addr is the location where kernel is actually being loaded and
will be run from. delta is the difference between compile time address
and run time address. 

KASLR is disabled by default. I am wondering that why do we have to
go through handle_relocations() if KASLR is disabled. Should we fall
back to old logic of manipulating page tables.

Or we need to figure out how to make handle_relocations() work in such
a way that kernel can be loaded anywhere in the memory. 

I suspect that 32bit relocations might not be able to handle it and
we probably might need all 64bit relocations to handle that case. But
with this resulting virtual addresses might still be the problem.

I summary, I am wondering what kind of limitation handle_relocations()
put on physical location of kernel and how can we remove that restriction
to be able to load kernel anywhere in memory.

Thanks
Vivek