LWN: Comments on "Kernel address randomization"

Kernel address randomization

kevinm — Mon, 11 Jul 2011 04:40:10 +0000

So long as the Oops includes the blinding value that was in use, and you can force it for subsequent testing via kernel command-line, that should be enough.

Kernel address randomization

PaXTeam — Sat, 28 May 2011 22:13:35 +0000

> the issue is that that 1/2/3G of kernel space is in a total of 4G of
> address space, and given the size of the kernel and the alignment
> requirements, things are a bit limited

the exact same limits apply to amd64 kernels as well.

> on amd64 you have much more address space to work with, so that 2G of
> kernel space can be moved to far more locations

you're wrong, the kernel image cannot be at arbitrary addresses, it *must* be in the top 2GB of the 64 bit virtual address space. i suggest you study the amd64 ABI and in particular -mcmodel=kernel.

Kernel address randomization

viro — Sat, 28 May 2011 20:42:09 +0000

... and if the crash depends on the location of kernel and simply doesn't happen on half of the boot attempts due to differences in that? Good luck narrowing things down to commit that has caused it...

Kernel address randomization

dlang — Fri, 27 May 2011 22:49:51 +0000

the issue is that that 1/2/3G of kernel space is in a total of 4G of address space, and given the size of the kernel and the alignment requirements, things are a bit limited

on amd64 you have much more address space to work with, so that 2G of kernel space can be moved to far more locations

Kernel address randomization

PaXTeam — Fri, 27 May 2011 22:38:28 +0000

i386 kernels have 1/2/3GB of kernel space to play with (minus vmalloc/fixmap/gaps/etc), amd64 kernels have 2GB (minus vsyscall/module area/etc). so for practical purposes, you could get the same amount of entropy for both cases.

Kernel address randomization

oak — Fri, 27 May 2011 22:10:02 +0000

>This should make bisecting a kernel problem fun, especially if the address
>layout only makes the problem appear on average half the time.

>Same with trying to reproduce a hang that locks your system only some of
>the time. Did you remember to write down the random offset at boot-time
>just in case?"

If the crash happens always "at the same place", and the kernel address is e.g. 4kB aligned, the lower bits would still be the same and could work as identification.

This isn't security through obscurity

david.a.wheeler — Fri, 27 May 2011 20:09:28 +0000

This isn't security through obscurity at all. In "security through obscurity" you're trying to hide how the system is designed, under the theory that no one could ever find out (ha!). This doesn't try to hide the design at all; here, you're countering an attacker even if the attacker knows this is going on (hopefully). Using unknown, easily-changed data to make a system hard to attack is well-accepted; passwords and crypto keys are also based on this idea.

Kernel address randomization

deater — Fri, 27 May 2011 12:50:31 +0000

This should make bisecting a kernel problem fun, especially if the address layout only makes the problem appear on average half the time.

Same with trying to reproduce a hang that locks your system only some of the time. Did you remember to write down the random offset at boot-time just in case?

There can also be interesting performance analysis implications. Randomized userspace processes can vary a few percent in performance when randomized if poorly written (SPEC 2000 perlbench (*cough*)). Things like taking addresses of variables and using them as keys in hash tables, etc.

Kernel address randomization

ebirdie — Thu, 26 May 2011 11:17:57 +0000

Really interesting, thank you.

What I can say, the boot time offset randomization should make every running kernel different in the World, of course, until every running kernel has this feature in effect. Further, this should make automated hack attempts a bit harder.

Combined to the above I came to think about this LWN.net article a while back: Persistent storage for a kernel's "dying breath", https://lwn.net/Articles/434821/.

It would be interesting to have a snapshot of the system after an oops caused by kernel memory poking. After a while, an active and automatic detection system could be useful to analyze and put aside the easy oops snapshots. Just wondering, if anybody already does this and this way gathers valuable information?

Kernel address randomization

dlang — Thu, 26 May 2011 07:14:06 +0000

no, 32 bit has very little flexibility, this is the gains for 64 bit systems

Kernel address randomization

jonabbey — Thu, 26 May 2011 04:32:15 +0000

This sounds a bit better than just 'security through obscurity'. Random numbers are used in all public key crypto systems, and we don't describe those systems as STO.

If randomization of the kernel addresses can give 8-12 bits of uncertainty and the kernel will tend to fail in obvious ways if they guess wrong, that's pretty darn good.

By the by, does this 8-12 bits of uncertainty figure hold true for both 32bit and 64bit x86?