Hacker News new | comments | show | ask | jobs | submit login
KARL – kernel address randomized link (OpenBSD) (marc.info)
81 points by brynet on June 13, 2017 | hide | past | web | favorite | 13 comments



I like the follow-up message: https://marc.info/?l=openbsd-tech&m=149732265506347&w=2

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.


So this seems like a "cheaper" alternative to KASLR? I.E. the kernel gains randomization without having to make all parts of it play nice with KASLR?

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


ASLR randomizes the based address, not per TU.


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.


There have been efforts trying to do the exact opposite of this, and enable reproducible builds.

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.


If the seed is saved, you get reproducibly randomized builds.


Use the (hash of the) source code to seed the CPRNG.


Probably. CompSci has been doing similar stuff for DARPA and NSF under banner of "moving target," "security through diversity," and various forms of the word obfuscation. I know you'll get at least one Googling survey moving target security.

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.


That's a good idea. I wonder how difficult it would be to teach GCC's linker to do that.


```within a compilation unit```

It's the compiler that needs to do the job.


I think both can do it.

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 :)


Could somebody explain the difficulties of implementing true ASLR for the kernel?


Loved this.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: