On 10/15/14 at 11:37am, Baoquan He wrote: > On 10/14/14 at 08:49am, Vivek Goyal wrote: > > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote: > > > 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: Hi hpa, About kaslr, do you have a suggestion or plan? Should we fix bug based on current code, or any other solutions? Thanks Baoquan > > 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. > -- 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