Subject: Re: [PATCH] static_call: use CFI-compliant return0 stubs

From: Carlos Llamas <[email-masked]>
Date: Thu, 12 Mar 2026 17:18:51 +0000

On Thu, Mar 12, 2026 at 09:07:40AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 12, 2026 at 08:40:11AM +0100, Ard Biesheuvel wrote:
> > So far, we have managed to avoid the blessings of objtool on arm64,
> > and the complexity associated with the inline patching is not really
> > justified, given that on arm64, there is not really a need to avoid
> > indirect calls (and as Peter says, we might end up with them anyway)
> > 
> > A while ago, I had a stab at implementing the out-of-line variety [0],
> > but nobody cared enough to even respond. It is rather concise, and
> > localised to arm64, so it is something we might consider for
> > CONFIG_CFI builds. It is essentially the same sequence that arm64 uses
> > for trampolines between modules and the kernel if they are out of
> > direct branching range, with some .rodata patching to change the
> > target. (arm64 basically only permits code patching without stopping
> > the machine when it involves patching branch opcodes into NOPS or vice
> > versa).

Great! I'll go read your implementation then.

> > Doing so for only CONFIG_CFI makes sense because it removes the CFI
> > overhead for all static calls, although it adds back some overhead for
> > the trampoline. But there is currently no need to do this
> > unconditionally.
> 
> Right, so your v3 is very simple and straight forward, and should work
> as an end run around the CFI issue, by effectively doing that indirect
> tail call in the trampoline outside of the compiler generated software
> cfi things.
> 
> And I think I like your thing better because it handles all possible
> cases, not just the ret0 oddity and isn't in fact much larger.

SGTM, I'll switch over to testing Ard's patch.

Thanks,
Carlos Llamas