From: Sami Tolvanen <samitolvanen@google.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
llvm@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Fangrui Song <i@maskray.me>,
Joao Moreira <joao@overdrivepizza.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Subject: Re: kCFI && patchable-function-entry=M,N
Date: Thu, 3 Apr 2025 20:15:34 +0000 [thread overview]
Message-ID: <20250403201534.GA197065@google.com> (raw)
In-Reply-To: <Y1Z12xuY9fDaHuCm@FVFF77S0Q05N>
Hi folks,
On Mon, Oct 24, 2022 at 12:24:11PM +0100, Mark Rutland wrote:
> On Sat, Oct 22, 2022 at 04:57:18PM +0200, Peter Zijlstra wrote:
> > On Fri, Oct 21, 2022 at 04:56:20PM +0100, Mark Rutland wrote:
> > > Hi,
> > >
> > > For arm64, I'd like to use -fatchable-function-entry=M,N (where N > 0), for our
> > > ftrace implementation, which instruments *some* but not all functions.
> > > Unfortuntately, this doesn't play nicely with -fsanitize=kcfi, as instrumented
> > > and non-instrumented functions don't agree on where the type hash should live
> > > relative to the function entry point, making them incompatible with one another.
> > > AFAICT, there's no mechanism today to get them to agree.
> > >
> > > Today we use -fatchable-function-entry=2, which happens to avoid this.
> >
> > > ... but I understand that for x86, folk want the pre-function NOPs to
> > > fall-through into the body of the function.
> >
> > Yep.
> >
> > > Is there any mechanism today that we could use to solve this, or could we
> > > extend clang to have some options to control this behaviour?
> >
> > So the main pain-point for you is differentiating between function with
> > notrace and those without it, right?
> >
> > That is; suppose you (like x86) globally do:
> > -fpatchable-function-entry=4,2 to get a consistent function signature,
> > you're up a creek because you use the __patchable_function_entries
> > section to drive ftrace and now every function will have it.
> >
> > So perhaps something like:
> >
> > -fpatchable-function-entry=N,M,sectionname
> >
> > would help, then you can have notrace be the same layout, except a
> > different section. Eg. something like:
> >
> > #define notrace __attribute__((patchable_function_entry(4,2,__notrace_function_entries)))
>
> FWIW, I think that'd work for me, and that was roughly my original proposal on
> IRC. My only concern with this approach is code size, since all uninstrumented
> functions gain some point less prefix NOPs.
It took me a couple of years to find the time to look into this,
but here's a Clang patch I committed yesterday that adds support
for a section parameter:
https://github.com/llvm/llvm-project/commit/acc6bcdc504ad2e8c09a628dc18de0067f7344b8
Sami
prev parent reply other threads:[~2025-04-03 20:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 15:56 kCFI && patchable-function-entry=M,N Mark Rutland
2022-10-21 15:56 ` Mark Rutland
2022-10-21 17:39 ` Sami Tolvanen
2022-10-21 17:39 ` Sami Tolvanen
2022-10-22 4:14 ` Fangrui Song
2022-10-22 4:14 ` Fangrui Song
2022-10-24 11:18 ` Mark Rutland
2022-10-24 11:18 ` Mark Rutland
2022-10-24 18:37 ` Sami Tolvanen
2022-10-24 18:37 ` Sami Tolvanen
2022-10-22 14:57 ` Peter Zijlstra
2022-10-22 14:57 ` Peter Zijlstra
2022-10-24 11:24 ` Mark Rutland
2022-10-24 11:24 ` Mark Rutland
2023-01-04 17:30 ` Fangrui Song
2023-01-04 17:30 ` Fangrui Song
2025-04-03 20:15 ` Sami Tolvanen [this message]
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=20250403201534.GA197065@google.com \
--to=samitolvanen@google.com \
--cc=i@maskray.me \
--cc=joao@overdrivepizza.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.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.