Re: [PATCH V2 5/9] objtool: Add support for intra-function calls

[Alexandre Chartre]

On 4/8/20 6:04 PM, Julien Thierry wrote:
> On 4/8/20 5:03 PM, Alexandre Chartre wrote:
> > On 4/8/20 4:19 PM, Julien Thierry wrote:
> > > On 4/8/20 3:06 PM, Alexandre Chartre wrote:
> > > > On 4/7/20 3:28 PM, Alexandre Chartre wrote:
> > > > > On 4/7/20 3:07 PM, Peter Zijlstra wrote:
> > > > > > On Tue, Apr 07, 2020 at 09:31:38AM +0200, Alexandre Chartre wrote:
> > > > > >
> > > > > > > index a62e032863a8..7ee1561bf7ad 100644
> > > > > > > --- a/tools/objtool/arch/x86/decode.c
> > > > > > > +++ b/tools/objtool/arch/x86/decode.c
> > > > > > > @@ -497,3 +497,15 @@ void arch_initial_func_cfi_state(struct cfi_state *state)
> > > > > > > ÂÂÂÂÂ state->regs[16].base = CFI_CFA;
> > > > > > > ÂÂÂÂÂ state->regs[16].offset = -8;
> > > > > > > Â }
> > > > > > > +
> > > > > > > +
> > > > > > > +void arch_configure_intra_function_call(struct stack_op *op)
> > > > > > > +{
> > > > > > > +ÂÂÂ /*
> > > > > > > +ÂÂÂÂ * For the impact on the stack, make an intra-function
> > > > > > > +ÂÂÂÂ * call behaves like a push of an immediate value (the
> > > > > > > +ÂÂÂÂ * return address).
> > > > > > > +ÂÂÂÂ */
> > > > > > > +ÂÂÂ op->src.type = OP_SRC_CONST;
> > > > > > > +ÂÂÂ op->dest.type = OP_DEST_PUSH;
> > > > > > > +}
> > > > > >
> > > > > > An alternative is to always set up stack ops for CALL/RET on decode, but
> > > > > > conditionally run update_insn_state() for them.
> > > > > >
> > > > > > Not sure that makes more logical sense, but the patch would be simpler I
> > > > > > think.
> > > > >
> > > > > Right, this would avoid adding a new arch dependent function and the patch
> > > > > will be simpler. This probably makes sense as the stack impact is the same
> > > > > for all calls (but objtool will use it only for intra-function calls).
> > > >
> > > > Actually the processing of the ret instruction is more complicated than I
> > > > anticipated with intra-function calls, and so my implementation is not
> > > > complete at the moment.
> > > >
> > > > The issue is to correctly handle how the ret is going to behave depending how
> > > > the stack (or register on arm) is modified before the ret. Adjusting the stack
> > > > offset makes the stack state correct, but objtool still needs to correctly
> > > > figure out where the ret is going to return and where the code flow continues.
> > >
> > > A hint indicating the target "jump" address could be useful. It could
> > > be used to add the information on some call/jump dynamic that aren't
> > > associated with jump tables. Currently when objtool finds a jump
> > > dynamic, if no branches were added to it, it will just return.
> > >
> > > Having such a hint could help make additional links (at least on
> > > arm64). I don't know what Peter and Josh would think of that (if that
> > > helps in your case of course).
> >
> > Yes, I am thinking about tracking intra-function call return address,
> > and having hints to specify a return address changes. For example,
> > on x86, when we push the branch address on the stack we overwrite the
> > last return address (the return address of the last intra-function call).
> > Then the return instruction can figure out where to branch.
>
> I see, I was thinking about a more generic hint, that would just
> indicate "this instruction actually jumps here". So in your case it
> would just point that a certain return instruction causes to branch
> somewhere.

I thought about doing that but the problem is that on x86 the same
retpoline code can branch differently depending on how it is used.
Basically we have a return instruction that will branch differently
based on what's on the stack. So we can just tell that this ret
instruction will branch/return there.

alex.

> This way the hint could also be used for other instructions (e.g.
> INSN_JUMP_DYNAMIC).