On Thu, Aug 21, 2014 at 02:10:00PM -0400, Vivek Goyal wrote: [..] > If kernel always moves itself to higher addresses then one solution could > be that load everything else below kernel and load kernel at higher > addresses. But old kexec system call will not be able to cope with it as > user space determines the load location of kernel and other segments while > running kernel decides location of pages for page table and kernel has > no idea where user space has loaded new kernel. New system call still > might be able to handle it. So I am reading kaslr code a bit. First of all we are moving kernel in physical address space. That would substantiate the theory that kernel movement stepped onto something. Basically we seem to be just going through all the e820 entries, putting them one slots[] array and choosing one entry randomly. That means kernel could move up or down. So the notion of loading everything else below kernel will not work. Now this makes me wonder that how does this whole thing work with grub. IOW, how would one make sure that kernel does not stomp initramfs. I guess only protection is BASE_MAX_OFFSET and making sure initramfs is loaded higher than that. If that's the case, then I think minimum and maximum range of physical memory where kernel can move should be exported through bzImage header and kexec-tools should make sure that anything else is outside of that range so that new kernel will not stomp over it. Thanks Vivek
