The typical approach of sliding the kernel around only offers limited benefit. One leaked address and you're done.
The current approach, called KARL, relinks the kernel so that while it may load at the same address, symbols internally do not have the same offset. Learning the address of printf will not reveal the address of malloc and so forth. In the context of kernel defense, I would argue this is more effective.
Also, simply as a practical matter, the bootloader and kernel are tightly coupled in ways that make altering the load address a nontrivial endeavor.
"The difference between the two is that KARL loads a different kernel binary in the same place, while KASLR loads the same binary in random locations. Same goal, different paths."
You'd be shocked to know how long after this was shown academically to be a Good Idea™ it took to get it into operating systems like Windows. The reason back then was because application programmers depended (incorrectly!) on sequential allocations so when you started randomizing things you'd break stuff.
Idk if that's the case here but its been a big reason historically.
I know OpenBSD doesn't prioritize new features but KASLR is a pretty significant security improvement, right?
The current approach, called KARL, relinks the kernel so that while it may load at the same address, symbols internally do not have the same offset. Learning the address of printf will not reveal the address of malloc and so forth. In the context of kernel defense, I would argue this is more effective.
Also, simply as a practical matter, the bootloader and kernel are tightly coupled in ways that make altering the load address a nontrivial endeavor.