From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Mark Rutland <mark.rutland@arm.com>,
Kees Cook <keescook@chromium.org>,
Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH] ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()
Date: Tue, 18 Oct 2022 17:02:41 +0200 [thread overview]
Message-ID: <Y07AEa7A73f1nDL1@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20221018102100.5aa55644@gandalf.local.home>
On Tue, Oct 18, 2022 at 10:21:00AM -0400, Steven Rostedt wrote:
> On Tue, 18 Oct 2022 14:35:15 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > Different function signatures means they needs to be different
> > functions; otherwise CFI gets upset.
>
> This is due to this commit:
>
> commit b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Date: Tue Oct 15 09:00:55 2019 -0400
>
> fgraph: Fix function type mismatches of ftrace_graph_return using ftrace_stub
>
> The C compiler is allowing more checks to make sure that function pointers
> are assigned to the correct prototype function. Unfortunately, the function
> graph tracer uses a special name with its assigned ftrace_graph_return
> function pointer that maps to a stub function used by the function tracer
> (ftrace_stub). The ftrace_graph_return variable is compared to the
> ftrace_stub in some archs to know if the function graph tracer is enabled or
> not. This means we can not just simply create a new function stub that
> compares it without modifying all the archs.
>
> Instead, have the linker script create a function_graph_stub that maps to
> ftrace_stub, and this way we can define the prototype for it to match the
> prototype of ftrace_graph_return, and make the compiler checks all happy!
>
>
> Perhaps its time to just modify all the archs and get rid of that hack.
Ideally yes, but given kCFI is in Linus' tree now, I didn't feel like
fixing up all archs in a hurry.
Mark mentioned that most archs can probably move to a common empty C
function for each stub.
next prev parent reply other threads:[~2022-10-18 15:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 12:35 [PATCH] ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph() Peter Zijlstra
2022-10-18 12:36 ` Peter Zijlstra
2022-10-18 13:18 ` Peter Zijlstra
2022-10-18 13:26 ` Mark Rutland
2022-10-18 14:28 ` Kees Cook
2022-10-18 15:00 ` Peter Zijlstra
2022-10-18 18:22 ` Kees Cook
2022-10-18 14:21 ` Steven Rostedt
2022-10-18 15:02 ` Peter Zijlstra [this message]
2022-10-20 15:17 ` [tip: x86/urgent] " tip-bot2 for 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=Y07AEa7A73f1nDL1@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.