linux-kernel - Re: [RFC][PATCH] Randomize kernel base address on boot

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]

Date:	Sun, 29 May 2011 20:44:09 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dan Rosenberg <drosenberg@...curity.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tony Luck <tony.luck@...il.com>,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	adobriyan@...il.com, penberg@...nel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Valdis.Kletnieks@...edu, pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot


* H. Peter Anvin <hpa@...or.com> wrote:

> On 05/29/2011 05:47 AM, Ingo Molnar wrote:
> > 
> > Do you mean we'd not start at a 2MB boundary and thus would waste on 
> > average an about 0.125 worth of huge-TLB cache entry?
> > 
> > That does not look like a very big issue to me - but maybe i'm 
> > missing something and you mean something else.
> > 
> 
> The problem is that because of the misalignment, and whatever falls 
> on the other side of that memory boundary we might end up having to 
> fracture the 2 MB page into 4K pages.

We already have that kind of fragmentation anyway, due to NX and due 
to the readonly area. Randomization does not really make that 
situation much worse.

But the thing is, we could fully eliminate all those disadvantages on 
64-bit x86:

We could put a 2MB hole between end of text (end of X) and start of 
readonly data (start of NX), and another 2MB hole between end of 
readonly and start of data.

That way we'd have:

 - the low alias is mapped NX as well, so the whole area and 
   surrounding pages are 2MB aligned. The 'holes' are freed up as 
   __initmem so not wasted.

 - the high alias will have three areas:

    - the    text area, which is 2MB mapped as X
    - the ro-data area, which is 2MB mapped as NX-RO
    - the    data area, which is 2MB mapped as NX-RW

because there's at least 2MB of distance between end of text and 
start of data there's a guarantee that both will be fully 2MB mapped.

Btw., we might want to do this regardless of randomization, for 
performance reasons: right now the NX and readonly area fragments the 
2MB mapping around the kernel text already, into 4K mappings.

Hm?

Thanks,

	Ingo
--
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/