KARL – kernel address randomized link (OpenBSD)
marc.info
marc.info
For those who are curious, here is the surprisingly small diff. No C code.
Perhaps in the future some valient soul will add a linker to the bootblocks, and we can boot a "bsd.a" file. For now this mechanism is easier; we can take a shot at adding KVA and KPA ASLR to the mix on a per-arch basis.
I should dig into the diffs but is link ordering recorded? It seems like this would be useful to have from a debugging perspective.
Edit: Yes the link ordering is recorded. http://marc.info/?l=openbsd-tech&m=149732265506347&w=2
It is a shame that the compiler and linker don't implement randomization instead. This would be generally useful beyond OpenBSD too.
It's the compiler that needs to do the job.
The compiler can do it within the compilation unit, randomizing the order of the blocks and globals.
The basic linker just quickly concatenates compilation units, but randomizes the order that it concatenates the units and randomizing the GOT and PLT order.
A link-time-optimizing linker can actually randomize the order of the blocks and globals and the compiler wouldn't need to be involved.
On the Mill CPU project we plan to randomize the order of everything each time we 'specialize'; kernels and user-space will have randomized GOT and block order on every installation, and it also helps smoke out bugs :)
Anyway, it's doable down to the ISA. The state-of-the-art last I checked was individual programs having keys that CPU used to descramble them or something with key's memory isolated from everything. Others just encrypt and authenticate RAM at CPU level giving specific sections to processes. There were compiler-assisted versions of each before that with big, performance hit.
Being able to compile code and get the same byte-for-byte result as someone else (i.e. a distribution shipping you binaries) can help eliminate concerns about binaries being tampered either accidentally or intentionally. This is a valuable security feature for some.