[PATCH] D31112: Proposal: Backward-edge CFI for return statements (RCFI)

[Kostya Serebryany via llvm-commits]

On Mon, Mar 27, 2017 at 12:04 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> On Wed, Mar 22, 2017 at 12:29 AM, Kostya Serebryany via Phabricator
> via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> > kcc added a comment.
> >
> >>> But I foresee that as being difficult
> >
> > Yep. That pesky phase-ordering again.
> >
> >
> > Repository:
> >   rL LLVM
> >
> > https://reviews.llvm.org/D31112
>
>
> FWIW another option for general case that may be faster.
>
> We emit a unique hash after each call instruction:
>
>   call <foo>
>   nop $0x12345678 // can use nop disp
>

This is similar to Intel's ENDBRANCH, but applied to RET instead of CALL
and with a callee-specific hash instead of a global one.

This protection may be bypassed in the presence of a JIT
if the attacker may force the JIT to emit the code containing the magic
bytes.

But otherwise, yes, that's yet another option to consider (we've discussed
it quite a few times offline),
and the compiler analysis required here is very similar.

--kcc


> The hash is associated with the callee. Callee checks that there is a
> correct hash at the return site:
>
> <foo>:
>   ...
>   mov 8(%rsp), %r8
>   cmpd 2(%r8), $0x12345678
>   jne bad
>   ret
>
> Can also use pop+jmp, not sure if it's faster:
>
> <foo>:
>   ...
>   pop %r8
>   cmpd 2(%r8), $0x12345678
>   jne bad
>   jmp %r8
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170329/4c43ddd6/attachment.html>