On Mon, Jan 04, 2021 at 09:16:33AM -0600, Josh Poimboeuf wrote: > > There's another fun scenario: > > > > 0x00 CALL *pv_ops.save_fl PUSHF > > 0x01 NOP2 > > .. > > 0x03 NOP5 > > .. > > 0x07 NOP2 > > 0x08 POP %RAX > > 0x09 <insn> > > > > No conflicting boundary at 0x07, but still buggered. > > > > Let me go read the actual patch to see if this is handled. > > That scenario looks good, see ORC below: > > .diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index cad08703c4ad..4079a430ab3f 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -1483,3 +1483,8 @@ SYM_CODE_START(rewind_stack_do_exit) > call do_exit > SYM_CODE_END(rewind_stack_do_exit) > .popsection > + > +SYM_FUNC_START(peter) > + ALTERNATIVE "call *pv_ops+288(%rip); .byte 0x66,0x90", "pushf; .byte > 0x66,0x90; .byte 0x66,0x66,0x66,0x90; popq %rax", X86_FEATURE_ALWAYS > + ret > +SYM_FUNC_END(peter) > > > 00000000000014e0 <peter>: > 14e0: ff 15 00 00 00 00 callq *0x0(%rip) # 14e6 > <peter+0x6> > 14e2: R_X86_64_PC32 pv_ops+0x11c > 14e6: 66 90 xchg %ax,%ax > 14e8: c3 retq > > alt replacement: > cf: 9c pushfq > d0: 66 90 xchg %ax,%ax > d2: 66 66 66 90 data16 data16 xchg %ax,%ax > d6: 58 pop %rax > > > > ORC: > > .entry.text+14e0: sp:sp+8 bp:(und) type:call end:0 > .entry.text+14e1: sp:sp+16 bp:(und) type:call end:0 > .entry.text+14e6: sp:sp+8 bp:(und) type:call end:0 > .entry.text+14e7: sp:sp+16 bp:(und) type:call end:0 > .entry.text+14e8: sp:sp+8 bp:(und) type:call end:0 > .entry.text+14e9: sp:(und) bp:(und) type:call end:0
Aaah, I was thinking the (LHS) NOP2 lookup would find the (RHS) PUSHF and fail, but yes, it will emit it's own +8 and find that ofcourse! So then yes, we only need to concern outselves with same offset conflicts, and that does indeed simplify things considerably.
