The relative order within a compilation unit is still predictable?
It is a shame that the compiler and linker don't implement randomization instead. This would be generally useful beyond OpenBSD too.
It is a shame that the compiler and linker don't implement randomization instead. This would be generally useful beyond OpenBSD too.
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.
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.
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 :)