Contributed by rueda on from the If you break it you buy it, no returns please dept.
Theo de Raadt (deraadt@) posted to
tech@
a detailed
message
explaining the past and (potential) future of
anti-ROP
measures in OpenBSD.
It's well worth reading its entirety. Highlights include:
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. […] We were able to enable RETGUARD on all functions because it was fast. […] On the other hand the RETGUARD approach uses an illegal instruction (of some sort), which is a speculation barrier. That prevents the cpu from heading off into an alternative set of weeds. It will go decode more instructions 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.
(Comments are closed)