Does OpenBSD have any plans to upstream RETGUARD to llvm?
Definitely. The llvm people I have spoken with have pointed out it might be better to implement in the preamble / epilogue lowering functions instead of as a pass, so once we prove it works in the ecosystem and have worked out any kinks, then I will do it that way and submit upstream.
Very cool! Thank you for the detailed answer.
Sure. Why not?
why are all the infosec people I follow charitably saying this is theatre at best and doesn’t do anything for any kind of attack?
The most common negative response I have seen is that this can be bypassed if an attacker knows the addresses they will write their rop chain to. This is true, but it is not the case that all attacks know the addresses where the rop chain goes. The @grsecurity response is interesting, since they point out that this idea has been seen before (quite some time ago - in 1999 and 2003). If you have heard other specific criticisms, then I’d be interested to hear them.
The next iteration of this doesn’t have to use the stack pointer - it can use something stronger. Step 1 is getting the ecosystem working with mangled return addresses. For this, the stack pointer is cheap and easy.
What is the overhead of this?
I love openbsd, though one of my coworkers told me he fundamentally disagrees with security by depth when we are starting to get memory safe language and I somewhat agree. While our useful kernels and applications are written in C, it seems like the best thing to do for now.
The overhead is two xor instructions per function call (using a register and the top of the stack). This is cheap.
Memory safe languages have their own overhead. Even rust - which achieves so much at compile time - still has to check for overflow at runtime in some situations, and doesn’t implement integer overflow protection because it is too expensive. I am a big fan of memory safe languages, but there is still a lot of C/C++ out there.
Maybe I am misunderstanding how this works, but why couldn’t you xor with a random constant for each function rather than the stack pointer? If possible it seems you could even re-randomize them at boot with that re-linking openbsd does and a magic reloc type.