Hacker News Reader

Comment by gbrown_ | Hacker News Reader

Another interesting point is ROP gadgets, which OpenBSD tries to reduce by preferring to avoid EBX/RBX registers [1]. This and more on the subject can be found in this paper [2].

[1] https://marc.info/?l=openbsd-tech&m=150869222214001&w=2

[2] https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf

View on HN

(Of course, it is dubious as to whether this actually helps much.)

> (Of course, it is dubious as to whether this actually helps much.)

Unsurprising, since the paper seems to be written by someone with no actual knowledge of x86 in the first place. Eg, in Alternate Code Generation, they recommend rewriting:

  48 89 C3  mov rbx, rax
  # as
  48 87 D8  xchg rax, rbx
  48 89 D8  mov rax, rbx
  48 87 D8  xchg rax, rbx
  # when they should simply be writing
  48 8B D8  mov rbx, rax  $ note that this is *literally the same instruction* at the assembly level

And even when the xchg's are actually needed (eg for mod/rm /0 and /1 opcode groups), they should be encoded properly:

  48 C1 C3 04  rol rbx, 4
  # to
  48 93        xchg rax, rbx  # we have dedicated instructions for this for a reason
  48 C1 C0 04  rol rax, byte 42
  48 93        xchg rax, rbx  # I think we *do* need the 48 on these, unfortunately; blame AMD

The former (that is, the policy of assembling register-to-register mod/rm instructions between a ax/cx and a bx/dx with the former in the effective address (not "destination") slot) eliminates upwards of three quarters of mod/rm-ret gadgets (including in hand-coded inline assembly!) at zero cost, and should have been the first option, before even thinking about register allocation.

Reply on news.ycombinator.com