Re: kernel aslr: someone interested?

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 25/03/2017 à 13:35, Joerg Sonnenberger a écrit :
> I don't think *any* of the cache latency problems have been fixed at
> all.

Yes, they haven't been fixed yet, but are being. I remember reading that
AMD was working on fixing that - I'll have to refind the article though.

> They are highly unlikely to be fixed as it would significantly
> impact performance and if CPUs have one design focus after correctness,
> it is performance. Some what I have seen, the consensus is that kernel
> ASLR can be considered ineffective for the text segment at the very
> least and many parts of the data structures as well as long as the
> attacker can execute (unprivileged) instructions on the CPU at will.

I don't quite understand what your point is. Correctness today also means
security, and in the recent years Intel and AMD have introduced many
features that they could have implemented twenty years ago (SMEP, SMAP,
UMIP, PKE, etc.).

None of us knows precisely how circuitry works on modern CPUs, and the
fact that in "cache latency" there is "cache" does not necessarily mean
that fixing it implies reducing performance. You can be sure that SMEP
adds some overhead on each instruction executed in kernel mode, but it
is a legitimate cost.

> As such, the point of "it makes bugs harder to exploit" is effectively
> false -- if you can force either the code path of interesting to be
> executed or any code path with a known offset, there is a generic method
> to compute the necessary address. It is just one more check mark in the
> exploit building tool.

? If there is a known offset you can do what you want, but the point is
precisely to randomize this offset. And yes, it does make bugs harder to
exploit, just like any form of ASLR available out there.

> There is a lot more effort involved than just providing an
> implementation. Just as it was easy to make everything PIE with ASLR
> without really caring about the fallout it creates in pkgsrc.

I disagree. You are comparing pkgsrc - which contains thousands of
potentially buggy packages written by many different people and
organizations, several of which do not exist anymore and do not fix their
buggy code - and the kernel, which is a simple software we edit.

If there is a fallout, I'll just fix it, and end of story.

> What is
> the impact kernel ASLR has debugability, performance and stability of
> performance? At least for the first item on the list, it will be pain.

In your list, I would have put performance first. There is almost no
impact on debugability: the symbols [1] remain in place, and the kernel
is relocated from there, so ddb can find the addresses just like on a
static kernel. Stability of performance does not change either.

What does change is the performance, and in this case it depends on how
we compile the kernel as PIE. ASLR would likely result in longer
instructions, slower to execute by the CPU. But as I said, many systems
support kernel aslr, and if the performance regression was that terrible
they wouldn't have enabled it.

Generally speaking, I would say that you are again using the same argument:
"things are black, we can't make them totally white, so no point in making
them grey". I could almost copy-paste the last paragraph of this mail [2]
I sent you a year ago, because you were already using the exact same
argument. Yes, security features aren't all perfect, but they remain
useful, regardless of whether you like them or not. Kernel ASLR is becoming
increasingly interesting and efficient, and that's almost a fact of life.


This time I insist, so if someone is interested, please let me know.


[1] https://nxr.netbsd.org/xref/src/sys/lib/libsa/loadfile_elf32.c#262
[2] http://mail-index.netbsd.org/tech-kern/2016/07/29/msg020924.html