OpenBSD Journal

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

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)


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]