Relocatable kernels - how much difference does it make?

Code:

% grep RELOCATABLE /boot/config-3.2.0-4-amd64 
CONFIG_RELOCATABLE=y

As you can see here from a kernel Makefile:
http://lxr.free-electrons.com/diff/arch/x86/Makefile?v=3.9;diffval=powerpc;diffvar=a

this makes the kernel a position independent executable (PIE). How much difference does this make vs. the chance of success for common types of kernel memory exploits?

e.g. I'd imagine that it might make it chancier to exploit a dangling pointer or use-after-free bug, since as with ASLR you don't know where the malicious code will land? It can't just be a matter of relative positioning within the kernel, I think, since your attack has to start off in user space.

OTOH it looks like modules are still loaded into predictable positions, so my hunch is this wouldn't do anything about an exploit against a driver compiled as a module...

Can anyone provide further info?

 

Even in the case where an exploit exists against a driver compiled as a module - in order to apply the exploit against the driver, it would have to find it first, eh? What proof is there that modules are loaded into predictable positions with regard to relocatable kernels?

-- Tom

 

Modules are specifically not compiled as PIE. Or does that not matter? Would the module's base position in memory be randomized as long as the the kernel itself is PIE?

 

As I understand it, a stack internal to the kernel's memory is used to keep track of where modules are loaded. Where a module is loaded depends on the space available in which to load and operate it. At runtime, where modules are always dynamically loaded in the same order, the necessary information in the stack as to each modules load location would have to be found after identifying the stack's location, and where load order is not always in a set order, the attacker would still have to be able to differentiate a target module's signature to determine it has the desired target.

 

So they really are dynamic. Cool. And thanks

 

Think about ASLR. In 32bit address spaces we focus so much on entropy because ~4GB is such a tiny space.

The kernel has 2GB address space. It also has 8bits of entropy for randomization.

It is also one contiguous blob

So, do I have to say how useful it is?

edit2: Also, keep in mind that the kernel boots up... well, early. So where's the entryop for the KASLR coming from? With Grsecurity you get a bit of an improvement here, but vanilla kernel's boned.

edit: Kernel modules do not have significant entropy typically, they are vmalloc'd objects (and therefor randmoized as such) that are typically loaded before entropy is significant - very early in the boot process. They are in the kernel address space, a smaller portion of it, so, again, not a lot of entropy here.