Viable ROP-free roadmap for i386/armv8/riscv64/alpha/sparc64

Theo de Raadt (deraadt@) posted totech@a detailedmessageexplaining the past and (potential) future ofanti-ROPmeasures in OpenBSD.

It's well worth reading its entirety.Highlights include:

Years later, Todd Mortimer and I developed RETGUARD. At the start ofthat initiative he proposed we protect all functions, to try to guardall the RET instructions, and therefore achieve a state we call"ROP-free". I felt this was impossible, but after a couple hurdles theRETGUARD performance was vastly better than the stack protector and wewere able to protect all functions and get to ROP-free (on fixed-sizedinstruction architecures). Performance was acceptable to trade againstimproved security.[...]We were able to enable RETGUARD on all functions because it was fast.[...]On the other hand the RETGUARD approach uses an illegal instruction (ofsome sort), which is a speculation barrier. That prevents the cpu fromheading off into an alternative set of weeds. It will go decode moreinstructions along the post-RET execution path.I filed that idea as interesting but did nothing with it. Until now.

Like we said earlier, it is worth reading the whole thing! This points forward to some remarkable improvements on several architectures, and those changes could be a clear benefit for other systems too.