linux-kernel - Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141015202227.GG3450@redhat.com>
Date:	Wed, 15 Oct 2014 16:22:27 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Baoquan He <bhe@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.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 Wed, Oct 15, 2014 at 11:37:01AM +0800, 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:
> > > 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.

I am wondering where does this 4G limit come from? Without kaslr now
we are able to load kernels much higher than 4G. That would suggest
that we should be able to pick randomly any address above 4G too?

Thanks
Vivek
--
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/