On 10/14/14 at 08:49am, Vivek Goyal wrote: > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote: > > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote: > > > On 10/13/2014 08:19 AM, Vivek Goyal wrote: > > > >>> > > > >>> This really shouldn't have happened this way on x86-64. It has to happen > > > >>> this way on i386, but I worry that this may be a serious misdesign in kaslr > > > >>> on x86-64. I'm also wondering if there is any other fallout of this? > > > >> > > > >> I agree. On x86_64, we should stick to previous design and this new > > > >> logic of performing relocations does not sound very clean and makes > > > >> things very confusing. > > > >> > > > >> I am wondering that why couldn't we simply adjust page tables in case of > > > >> kaslr on x86_64, instead of performing relocations. > > > > > > > > Well, IIUC, if virtual addresses are shifted w.r.t what virtual address > > > > kernel was compiled for, then relocation will have to be done. > > > > > > > > So question will be if physical address shift is enough for kaslr or > > > > virtual address shift is necessary. > > > > > > > > > > I would assume that without a virtual address shift kaslr is pretty darn > > > pointless. Without the physical address shift the 1:1 map can be used, > > > and again, kaslr becomes pointless. However, there is absolutely no > > > reason why they should be coupled. They can, in fact, be independently > > > randomized. > > > > Agreed. On x86_64, we should be able to randomize virtual address space > > and physical address space independently. And in that case whole of > > the physical memory should be available for a possible location for > > kernel. (As opposed to a small limit (I guess 1GB) now) It can be done to randomize virtual address space and physical address space independently. But limited by the 2G of kernel text mapping and module mapping virtual address space, virtual address can be randomized in (0x1000000, 1G) range. While physical address can be randomized in (0x1000000, 4G) according to the identity mapping of normal kernel. Then phys_base still stores an relative value, a different offset than before. This can be easily implement. One thing is still there's a limit for physical addr randomization, only below 4G. So I am wondering if we can extend the identify mapping to complete mapping of 48 bit, using 1G page frame. This can make physical addr be randomized to anywhere. So now there may be 3 options: 1) Fix this bug in current kaslr. Since when randomize the new kernel location in choose_kernel_location(), cmdline options has been checked strictly, e.g if nokaslr is specified, it's safe to do the kernel location randomization. Then in handle_relocations(), we only need to check if the kernel location is changed, comparing with kernel loaded addr. If changed, kaslr is done, let's do the relocation handling. If not changed, no kaslr id done, just skip the relocation handling like before. 2) randomize the virtual addr space and physical addr space independently. But physical addr space must be below 4G. 3) extend the identity mapping to 48bit of addr space. Then we can randomized the virtual addr space in (0x1000000, 1G) and physical addr space in (0x1000000, real physical memory end). If option 3 is doable, it's the best. If not, I think bug fix should be better. > > Hi Peter, > > So what do we do about this issue in short term to make kexec work. Even > if we go for above solution, to make kexec work we will have to pass > "nokaslr" as we don't want kernel to move around in physical address space > as it might stomp over ELF headers we have stored. kexec doesn't need ELF headers. Kdump may need it. But in current kexec-tools implementation, kernel/initrd and other stuffs are placed from top to down, current implementation won't do kaslr since it only happened between kernel loaded addr and 1G. So we don't need to worry about the stomping. > > If you don't like current patch, should we just disable relocations in > x86_64 if "nokaslr" command line is passed. That way kernel will not > be moved in physical as well as virtual address space. > > Thanks > Vivek -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html