Conversation

Halvar Flake
@halvarflake
I am not sure that many people with deep offensive experience would agree that fine-grained KASLR is a good solution here (but I've had this discussion many times in the past and am frankly tired that it keeps coming back).
Quote Tweet
Kees Cook
@kees_cook
2/n: single-leak KASLR exposure reinforcing the need for Function-Granular KASLR. While KASLR adds an additional hurdle, a single exposure will fully bypass it. Gaining FGKASLR would strongly diminish the value of a single exposure. github.com/KSPP/linux/iss
Show this thread
6
53
Kees Cook
@kees_cook
Replying to
@halvarflake
Yup, rational people disagree about this. I'm not suggesting it'll always be a win, but it is likely better than only KASLR. A little more of my thinking here:
Quote Tweet
Kees Cook
@kees_cook
Replying to @daveaitel
Different people measure the trade-offs differently. I've always held making mitigations _available_ is the key to progressive improvement. The devel, discussions, and use of mitigations leads to evolution of the space, whether it be the improvement or elimination of options.
1
Daniel Micay
@DanielMicay
Replying to
@kees_cook
@halvarflake
and
@tehjh
CFI + ShadowCallStack are already doing a good job against very constrained memory corruption bugs. I don't see what any mitigations short of detecting/preventing memory corruption can realistically do against more dangerous primitives. You can simply change process privileges.
1
3
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@kees_cook
and 2 others
ARMv8.5 memory tagging approach only has 4-bit tags. If you have 128-bit tags via fat pointers, you could have strong memory safety. At a certain point, it would be a whole lot less work and actually more performant to just implement memory safety instead of weak mitigations.
1
5
Show replies