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