Re: [BUG] perf: bogus correlation of kernel symbols

[Ingo Molnar <mingo@elte.hu>]

* 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