lkml.org 
[lkml]   [2011]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Randomize kernel base address on boot

* H. Peter Anvin <hpa@zytor.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


\
 
 \ /
  Last update: 2011-05-29 20:47    [from the cache]
©2003-2011 Jasper Spaans