3 ms·
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
by gbrown_ 6y ago
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 https://marc.info/?l=openbsd-tech&m=150869222214001&w=2
[2] https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf
- saagarjha 6y ago(Of course, it is dubious as to whether this actually helps much.)
- a1369209993 6y ago> (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.