Messages in this thread | | | Date | Sun, 29 May 2011 20:44:09 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |