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
next prev parent 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®