mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: alexandre.chartre@oracle.com, linux-kernel@vger.kernel.org,
	jthierry@redhat.com, tglx@linutronix.de, x86@kernel.org
Subject: Re: [RFC][PATCH 4/7] objtool: Add support for intra-function calls
Date: Sun, 19 Apr 2020 11:41:50 -0500	[thread overview]
Message-ID: <20200419164150.q5ut7gjhwzdrg4lf@treble> (raw)
In-Reply-To: <20200416151024.944613249@infradead.org>

On Thu, Apr 16, 2020 at 05:07:56PM +0200, Peter Zijlstra wrote:
> From: Alexandre Chartre <alexandre.chartre@oracle.com>
> 
> Change objtool to support intra-function calls. On x86, an intra-function
> call is represented in objtool as a push onto the stack (of the return
> address), and a jump to the destination address. That way the stack
> information is correctly updated and the call flow is still accurate.
> 
> Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Link: https://lkml.kernel.org/r/20200414103618.12657-4-alexandre.chartre@oracle.com
> ---
>  include/linux/frame.h                            |   11 +
>  tools/objtool/Documentation/stack-validation.txt |    8 +
>  tools/objtool/arch/x86/decode.c                  |   17 ++-
>  tools/objtool/check.c                            |  129 ++++++++++++++++++-----
>  tools/objtool/check.h                            |    1 
>  5 files changed, 140 insertions(+), 26 deletions(-)
> 
> --- a/include/linux/frame.h
> +++ b/include/linux/frame.h
> @@ -15,9 +15,20 @@
>  	static void __used __section(.discard.func_stack_frame_non_standard) \
>  		*__func_stack_frame_non_standard_##func = func
>  
> +/*
> + * This macro indicates that the following intra-function call is valid.
> + * Any non-annotated intra-function call will cause objtool to issue warning.

issue *a* warning

> +static int setup_call_dest(struct objtool_file *file, struct instruction *insn)
> +{
> +	unsigned long dest_off;
> +
> +	dest_off = insn->offset + insn->len + insn->immediate;
> +	insn->call_dest = find_func_by_offset(insn->sec, dest_off);
> +	if (!insn->call_dest)
> +		insn->call_dest = find_symbol_by_offset(insn->sec, dest_off);
> +
> +	if (!insn->call_dest) {
> +		/* intra-function call */
> +		if (insn->intra_function_call)
> +			return 0;
> +
> +		WARN_FUNC("intra-function call", insn->sec, insn->offset);
> +		return -1;
> +	}
> +
> +	/* regular call */
> +	if (insn->func && insn->call_dest->type != STT_FUNC) {
> +		WARN_FUNC("unsupported call to non-function",
> +			  insn->sec, insn->offset);
> +		return -1;
> +	}
> +
> +	return 0;
> +}
> +

This function should first be added in a separate patch which doesn't
change functionality.

> @@ -2269,6 +2327,29 @@ static int validate_branch(struct objtoo
>  			if (dead_end_function(file, insn->call_dest))
>  				return 0;
>  
> +			if (insn->intra_function_call) {
> +				/*
> +				 * The call instruction can update the stack
> +				 * state. Then make the intra-function call
> +				 * behaves like and unconditional jump.

grammar fix: "behave like an unconditional jump".

> +				 */
> +				ret = handle_insn_ops(insn, &state);
> +				if (ret)
> +					return ret;

validate_branch's callers aren't currently able to handle a negative
return code.

> +
> +				ret = validate_branch(file, func, insn,
> +						      insn->jump_dest, state);
> +				if (ret) {
> +					if (backtrace) {
> +						BT_FUNC("(intra-function call)",
> +							insn);
> +					}
> +					return ret;
> +				}
> +
> +				return 0;
> +			}
> +

Could this be cleaner if the insn->type were just changed to
INSN_JUMP_UNCONDITIONAL?  Then it could share the normal jump logic.

Also, now that more instructions are getting stack ops, I wonder if the
ops can just be handled generically for every instruction, with a call
to handle_insn_ops() above, before the switch statement.

-- 
Josh


  reply	other threads:[~2020-04-19 16:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 15:07 [RFC][PATCH 0/7] objtool vs retpoline Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 1/7] objtool: is_fentry_call() crashes if call has no destination Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 2/7] objtool: UNWIND_HINT_RET_OFFSET should not check registers Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 3/7] objtool: Allow branches within the same alternative Peter Zijlstra
2020-04-19 16:32   ` Josh Poimboeuf
2020-04-19 19:27     ` Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 4/7] objtool: Add support for intra-function calls Peter Zijlstra
2020-04-19 16:41   ` Josh Poimboeuf [this message]
2020-04-23 11:40     ` Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 5/7] x86/speculation: Change __FILL_RETURN_BUFFER to work with objtool Peter Zijlstra
2020-04-19 16:51   ` Josh Poimboeuf
2020-04-19 16:55     ` Josh Poimboeuf
2020-04-19 18:58       ` Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 6/7] x86/retpoline: Out-of-line retpoline Peter Zijlstra
2020-04-16 15:22   ` Peter Zijlstra
2020-04-16 15:07 ` [RFC][PATCH 7/7] x86/nospec: Remove ANNOTATE_NOSPEC_ALTERNATIVE Peter Zijlstra
2020-04-16 15:32 ` [RFC][PATCH 0/7] objtool vs retpoline Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200419164150.q5ut7gjhwzdrg4lf@treble \
    --to=jpoimboe@redhat.com \
    --cc=alexandre.chartre@oracle.com \
    --cc=jthierry@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®