Message-ID: <20141015235537.GA1642@dhcp-17-102.nay.redhat.com>
Date:	Thu, 16 Oct 2014 07:55:37 +0800
From:	Baoquan He <bhe@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, ak@...ux.intel.com, ebiederm@...ssion.com,
	kexec@...ts.infradead.org, whissi@...ssi.de,
	kumagai-atsushi@....nes.nec.co.jp, stable@...r.kernel.org
Subject: Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed

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

Powered by blists - more mailing lists