aarch64: add PAC-RET protection to libitm sjlj.S
authorSzabolcs Nagy <szabolcs.nagy@arm.com>
Thu, 16 Jul 2020 15:39:23 +0000 (16:39 +0100)
committerSzabolcs Nagy <szabolcs.nagy@arm.com>
Fri, 24 Jul 2020 10:44:53 +0000 (11:44 +0100)
commitab240ab50990c01cb657b4a4306ed6f4b2d4fb6e
treedfe4392b4a893998763a0ddce8db85637df8188f
parentedfb3a30a6cef8e8c25197a7534628961233d772
aarch64: add PAC-RET protection to libitm sjlj.S

_ITM_beginTransaction is a 'returns_twice' function that saves x30
on the stack as part of gtm_jmpbuf (that is passed down to
GTM_begin_transaction), but the saved x30 is also used for return.

The return path should be protected so we don't leave an
  ldp x29, x30, [sp]
  ret
gadget in the code, so x30 is signed on function entry. This
exposes the signed address in the gtm_jmpbuf too. The jmpbuf does
not need a signed address since GTM_longjmp uses
  ldp x29, x30, [x1]
  br x30
and with BTI there is a BTI j at the _ITM_beginTransaction call site
where this jump returns. Using PAC does not hurt: the gtm_jmpbuf is
internal to libitm and its layout is only used by sjlj.S so the
signed address does not escape. Saving signed x30 into gtm_jmpbuf
provides a bit of extra protection, but more importantly it allows
adding the PAC-RET support without changing the existing code much.

In theory bti and pac-ret protection can be added unconditionally
since the instructions are in the nop space, in practice they
can cause trouble if some tooling does not understand the gnu
property note (e.g. old binutils) or some unwinder or debugger
does not understand the new dwarf op code used for pac-ret (e.g
old gdb). So the code is written to only support branch-protection
according to the code generation options.

libitm/ChangeLog:

* config/aarch64/sjlj.S: Add conditional pac-ret protection.
libitm/config/aarch64/sjlj.S