Author: Thom Holwerda
Source
Years later, Todd Mortimer and I developed RETGUARD. At the start of that initiative he proposed we protect all functions, to try to guard all the RET instructions, and therefore achieve a state we call “ROP-free”. I felt this was impossible, but after a couple hurdles the RETGUARD performance was vastly better than the stack protector and we were able to protect all functions and get to ROP-free (on fixed-sized instruction architecures). Performance was acceptable to trade against improved security. RETGUARD provides up to 4096 cookies per DSO, per-function, but limited to avoid excessive bloat. It is difficult to do on architectures with very few registers. Code was only written for clang, there is no gcc codebase doing it. clang code for some architectures was never written (riscv64). I hope that sets the stage for what is coming next. We were able to enable RETGUARD on all functions because it was fast. Look, I have no clue what any of this means. None at all. However, I do somewhat grasp this is a big deal… I just need OSNews readers to explain in layman’s terms why, exactly.