
Linux-insides: Linux kernel load address randomization - 0xAX
https://github.com/0xAX/linux-insides/blob/master/Booting/linux-bootstrap-6.md
======
PyComfy
[https://thehackernews.com/2017/02/bypass-aslr-browser-
javasc...](https://thehackernews.com/2017/02/bypass-aslr-browser-
javascript.html)

[http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf](http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf)

 _XI. CONCLUSIONS

In this paper, we described how ASLR is fundamentally insecure on modern
architectures. Our attack relies on the interplay between the MMU and the
caches during virtual to physical address translation—core hardware behavior
that is central to efficient code execution on modern CPUs. The underlying
problem is that the complex nature of modern microarchitectures allows
attackers with knowledge of the architecture to craft a carefully chosen
series of memory accesses which manifest timing differences that disclose what
memory is accessed where and to infer all the bits that make up the address.
Unfortunately, these timing differences are fundamental and reflect the way
caches optimize accesses in the memory hierarchy. The conclusion is that such
caching behavior and strong address space randomization are mutually
exclusive. Because of the importance of the caching hierarchy for the overall
system performance, all fixes are likely to be too costly to be practical.
Moreover, even if mitigations are possible in hardware, such as separate cache
for page tables, the problems may well resurface in software. We hence
recommend ASLR to no longer be trusted as a first line of defense against
memory error attacks and for future defenses not to rely on it as a pivotal
building block._

~~~
saagarjha
In every context that I've seen it, ASLR is there to be annoying to circumvent
instead of being the sole line of defense. Generally other techniques are
present as well to mitigate the risk of such an attack.

------
solarengineer
An informative read on ASLR: [https://blog.polyverse.io/why-aslr-stops-rop-
attacks-8e961ca...](https://blog.polyverse.io/why-aslr-stops-rop-
attacks-8e961ca6951e)

------
monocasa
Outside of Linux, is there any point to ASLR in a provably memory safe kernel
like sel4? Like, I get the main point is to stop ROP gadgets, which obviously
aren't an issue when you can't corrupt memory. Are there side benefits though?

~~~
gok
Formally verified kernels are pretty rare, and you can always have bugs in
verification or side channel attacks that your proofs don’t cover, like
speculative execution timing bugs in your CPU. (K)ASLR doesn’t defeat all
memory bugs but it helps (a little). It is a very low overhead element of
defense in depth that doesn’t require major code changes (unlike say,
rewriting your kernel in a memory safe language).

~~~
monocasa
Sure, but those same speculative execution attacks also trivially defeat ASLR.
And practically speaking, memory safety in formally proved software tends to
be pretty bullet proof.

So, outside of memory unsafety, is there another threat profile where ASLR
gains you something?

~~~
gok
Sure, consider that the hashCode() of objects in Java are based on memory
addresses, which means they’re predictable to an attacker without ASLR.

------
ryanthedev
Am I the only one who sees this as gibberish and feels bad :(

~~~
kzrdude
I don't think a lot of people can jump into Page 6 of a document called Kernel
booting process and understand it.

It requires knowing something about the topic, and maybe some of those who
don't would have to look up and read about 1, 2, 5, 10 different topics that
show up in the article that they didn't know about before.

