[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] objtool: Support stack layout changes in alternatives



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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.