‘Kernel address randomised link’ masks memory locations
The changes are described in this note to an OpenBSD developer list penned by founder and lead developer Theo de Raadt.
The idea is to randomise how the kernel loads, so that kernel loading gets the same benefits as applies to (for example) application memory in ASLR (address space layout randomisation) – so an attacker can’t rely on predictable memory allocations to identify where a buffer overrun might land.
As de Raadt notes, after installation kernel binaries will run for months at a time and the kernel is “always in the same physical memory, at the same virtual address space (we call it KVA)”.
To fix this, de Raadt (with Visa Hankala and Patrick Wildt) has implemented a new model in which “every new kernel is unique”, and “The relative offsets between functions and data are unique.”
Instead of loading
locore.s (the kernel bootstrap), then the linked
c files deterministically, the new process he describes breaks the loading up somewhat: “Locore is split into two files: One chunk is bootstrap, that is left at the beginning. The assembly language runtime and all other files are linked in random fashion.”
The bootstrap isn’t yet random – it’s at a well-known address – so once the system is running, the kernel “blasts the bootstrap code into oblivion by smashing it with TRAP instructions or unmapping” (depending on the processor architecture).
Next in line, he writes, is to provide what he calls the “scaffolding” necessary to create a newly-linked kernel at every reboot – again to make it harder for hacker to predict memory locations. That’s not yet ready for prime time, because it’s “incompatible with the current workings of unhibernate”. ®