Date: Fri, 20 May 2011 20:28:38 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Rosenberg <drosenberg@vsecurity.com>, linux-kernel@vger.kernel.org,
        davej@redhat.com, kees.cook@canonical.com, davem@davemloft.net,
        eranian@google.com, adobriyan@gmail.com, penberg@kernel.org
Subject: Re: [BUG] perf: bogus correlation of kernel symbols
Message-ID: <20110520182838.GA12765@elte.hu>
References: <1305292059.1949.0.camel@dan>
 <1305293345.1949.22.camel@dan>
 <20110516153527.GC21107@elte.hu>
 <1305852966.3005.19.camel@dan>
 <20110520120750.GJ14745@elte.hu>
 <1305896093.3005.24.camel@dan>
 <20110520131108.GA17699@elte.hu>
 <1305913261.20623.12.camel@dan>
 <BANLkTinCnqrzMyoSzS04fCAqks1bd9Y8=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTinCnqrzMyoSzS04fCAqks1bd9Y8=g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-08-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2097
Lines: 46


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> There's a *big* detail that makes it hard: there's only a few bits of 
> randomness we can add to the address. The kernel base address ends up having 
> various fundamental limitations (cacheline alignment for the code, and we 
> have several segments that require page alignment), so you really can't 
> realistically do more than something like 8-12 bits of address randomization.

Yeah, i tried to address this issue in my first mail: basically just a few bits 
would already make a big difference in practice: even a *single* bit of 
randomness makes an exploit crash 50% of the time - at which point the attack 
stops being stealth.

8 bits would be a lot.

So i think this is really realistic, even if a brute force, networked attack 
can successfully attack 1 out of 256, 512 or 1024 boxes. Even for the worm cas 
the networked attack would not scale very well.

> Regardless, the virtual mapping trick (independently of whether it's 
> read-only or not) can be used to avoid exposing the *actual* address of the 
> IDT of the kernel, and would hide the kernel load address details. However, 
> it does make traps slightly slower, if they cannot use the 1:1 mapping with 
> large pages for the IDT access and thus cause more TLB pressure. Of course, 
> in many situations we probably end up not having large pages for the kernel 
> anyway, so..

We could put per CPU IDTs into the percpu area if that improves performance.

This might help on NUMA: on NUMA only one node has the IDT local, the others 
will take a remote DRAM access every time they miss the IDT - and the IDT could 
easily be missed if there are no IRQs or traps for a long time (say CPU-bound 
user-space processing).

There may also be cases where an implicit locked access is generated to the 
IDT?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/