From: Carlos Llamas <cmllamas@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
Quentin Perret <qperret@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
James Morse <james.morse@arm.com>, Will Deacon <will@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kees Cook <keescook@chromium.org>,
Sami Tolvanen <samitolvanen@google.com>,
Andy Lutomirski <luto@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v6 2/2] arm64: implement support for static call trampolines
Date: Thu, 12 Mar 2026 22:10:35 +0000 [thread overview]
Message-ID: <abM52-5Jq1E-Q-6c@google.com> (raw)
In-Reply-To: <83c36b0a-7e7d-4651-8e2c-86452c3bd96b@app.fastmail.com>
On Thu, Mar 12, 2026 at 07:35:34PM +0100, Ard Biesheuvel wrote:
> Hi Carlos,
>
> On Thu, 12 Mar 2026, at 19:02, Carlos Llamas wrote:
> > On Fri, Nov 05, 2021 at 03:59:17PM +0100, Ard Biesheuvel wrote:
> >> Implement arm64 support for the 'unoptimized' static call variety, which
> >> routes all calls through a single trampoline that is patched to perform a
> >> tail call to the selected function.
> >>
> >> It is expected that the direct branch instruction will be able to cover
> >> the common case. However, given that static call targets may be located
> >> in modules loaded out of direct branching range, we need a fallback path
> >> that loads the address into R16 and uses a branch-to-register (BR)
> >> instruction to perform an indirect call.
> >>
> >> Unlike on x86, there is no pressing need on arm64 to avoid indirect
> >> calls at all cost, but hiding it from the compiler as is done here does
> >> have some benefits:
> >> - the literal is located in .text, which gives us the same robustness
> >> advantage that code patching does;
> >> - no performance hit on CFI enabled Clang builds that decorate compiler
> >> emitted indirect calls with branch target validity checks.
> >>
> >> Acked-by: Peter Zijlstra <peterz@infradead.org>
> >> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >> ---
> >
> > I'm starting to testing this out on top of 7.0-rc3...
> >
>
> Please use the v3 I referred to on the thread. The code patching is a bit hairy, and so we should only consider that if there is a real use case for it.
>
> Same goes for the special handling of the ret0 case - AFAIR, the v3 handles that transparently as it will just use the generic RET0 handler as the target.
IIUC, the trampoline tests R16 and returns early if unset. However, for
the RET0 case the register would point to __static_call_return0 and then
do the indirect call anyway. I suppose CFI is fine with this as like you
mentioned, this is "hidden" from the compiler.
However, the R16 test seems unnecessary for the RET0 case, as it is
always set to _something_ right? Or maybe I'm missing something?
Either way, now that I've rebased the patch I can send a... v7? With the
required minor tweaks for RET0 and such.
--
Carlos Llamas
prev parent reply other threads:[~2026-03-12 22:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 14:59 [PATCH v6 0/2] static call support for arm64 Ard Biesheuvel
2021-11-05 14:59 ` [PATCH v6 1/2] static_call: use non-function types to refer to the trampolines Ard Biesheuvel
2021-11-08 10:08 ` Peter Zijlstra
2021-11-05 14:59 ` [PATCH v6 2/2] arm64: implement support for static call trampolines Ard Biesheuvel
2021-11-08 10:23 ` Peter Zijlstra
2021-11-08 11:29 ` Ard Biesheuvel
2021-11-08 11:52 ` Peter Zijlstra
2021-11-09 17:55 ` Mark Rutland
2021-11-09 18:09 ` Ard Biesheuvel
2021-11-09 19:02 ` Quentin Perret
2021-11-10 11:09 ` Mark Rutland
2021-11-10 12:05 ` Quentin Perret
2026-03-12 18:02 ` Carlos Llamas
2026-03-12 18:35 ` Ard Biesheuvel
2026-03-12 22:10 ` Carlos Llamas [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=abM52-5Jq1E-Q-6c@google.com \
--to=cmllamas@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=frederic@kernel.org \
--cc=james.morse@arm.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=will@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