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) Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
