LWN: Comments on "Randomizing the kernel"

Randomizing the kernel

heijo — Thu, 18 Apr 2013 12:56:08 +0000

Why not compile with one function and one global variable per section, keep section-based relocations in the kernel image, and then randomly shuffle the sections at boot?

That would only have a slight boot time and kernel image size overhead, both of which are irrelevant for servers, and probably not an issue anywhere else.

This way, guessing would be impossible, and any "leaks" would not give any information on the location of other functions or data other than the "leaked" one.

Randomizing the kernel

tialaramex — Fri, 12 Apr 2013 13:09:02 +0000

The earlier link is already mentioned in the article. Deciding whether defences are worthwhile is largely impossible unless you have in mind a specific threat model.

All ASLR-style defences have entirely practical statistical attacks, so if the threat you're modelling wouldn't be phased by that then it's worthless /for that model/. This is a contrast to something like W^X which isn't statistical, an attack that's stopped by W^X is stopped, maybe it can be re-activated by another route, but it can't just be retried (or used against more hosts) with the expectation that it will eventually work.

I make the distinction _entirely practical_ because there are theoretical statistical attacks against a lot of things which we can discount. We quite reasonably don't consider "just guessing" a 128 bit AES secret key to be a practical attack on a scheme using AES encryption for example.

Randomizing the kernel

Beolach — Thu, 11 Apr 2013 23:58:01 +0000

Just a couple weeks back, LWN posted a link to the PaX Team calling KASLR Cargo Cult Security. I quite liked the metaphor they used to illustrate how small a benefit it gives:

this moving target only moves once and is pretty easy to spot.

That said, even w/ only minuscule benefit, I think it might still be worthwhile, if it has an even more minuscule cost. Does anyone know if KASLR has any impact on performance?

Randomizing the kernel

error27 — Thu, 11 Apr 2013 12:54:20 +0000

This seems like a very simple and worthwhile step. Ubuntu has kptr_restrict turned on but it's useless without randomization.

It's true that there are still lots of information leaks left. Smatch has a check for some kinds of trivial leaks. I fixed a couple leaks last week.

But if you just keep on plugging away at it, these do get fixed eventually. The quality of kernel code really is getting better. I think of things like this as part of a five year project instead of as an end in themselves.