On 10/15/14 at 01:32pm, H. Peter Anvin wrote: > I don't see why we can't randomize anywhere in physical space. We already handle the kernel above 4 GB and it wouldn't be hard to do the equivalent for the decompress/relocation code, using a #PF handler. Not all CPUs support 1 GB pages. > Well, IIUC, in arch/x86/boot/compressed/head_64.S pgtable contains 6 page frames and is used to build 4G identity mapping. Then this pgtable is loaded into cr3. Later jump into 64bit mode. decompress/relocation code should work in this region. Isn't it right? Currently kernel surely can be put anywhere, even above 4G. This have been done very often in kexec/kdump. However in kexec/kdump the identity mapping is built for all physical memory after jumping to startup_64 directly from purgatory, that's why kexec/kdump kernel can be put anywhere. So for normal kernel, don't we need to extend the physical memory mappng to a larger region if we want to randomize anywhere in physical space? Thanks Baoquan > On October 14, 2014 8:37:01 PM PDT, Baoquan He <bhe at redhat.com> wrote: > >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 > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting.
