Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH 2/4] arm64: implement support for static call trampolines | Date | Mon, 25 Oct 2021 15:03:07 +0000 |
| |
From: Ard Biesheuvel > Sent: 25 October 2021 15:55 > > On Mon, 25 Oct 2021 at 16:47, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Mon, Oct 25, 2021 at 04:19:16PM +0200, Peter Zijlstra wrote: > > > On Mon, Oct 25, 2021 at 04:08:37PM +0200, Ard Biesheuvel wrote: > > > > > > > Ooohh, but what if you go from !func to NOP. > > > > > > > > > > assuming: > > > > > > > > > > .literal = 0 > > > > > BTI C > > > > > RET > > > > > > > > > > Then > > > > > > > > > > CPU0 CPU1 > > > > > > > > > > [S] literal = func [I] NOP > > > > > [S] insn[1] = NOP [L] x16 = literal (NULL) > > > > > b x16 > > > > > *BANG* > > > > > > > > > > Is that possible? (total lack of memory ordering etc..) > > > > > > > > > > > > > The CBZ will branch to the RET instruction if x16 == 0x0, so this > > > > should not happen. > > > > > > Oooh, I missed that :/ I was about to suggest writing the address of a > > > bare 'ret' trampoline instead of NULL into the literal. > > > > Perhaps a little something like so.. Shaves 2 instructions off each > > trampoline. > > > > --- a/arch/arm64/include/asm/static_call.h > > +++ b/arch/arm64/include/asm/static_call.h > > @@ -11,9 +11,7 @@ > > " hint 34 /* BTI C */ \n" \ > > insn " \n" \ > > " ldr x16, 0b \n" \ > > - " cbz x16, 1f \n" \ > > " br x16 \n" \ > > - "1: ret \n" \ > > " .popsection \n") > > > > #define ARCH_DEFINE_STATIC_CALL_TRAMP(name, func) \ > > --- a/arch/arm64/kernel/patching.c > > +++ b/arch/arm64/kernel/patching.c > > @@ -90,6 +90,11 @@ int __kprobes aarch64_insn_write(void *a > > return __aarch64_insn_write(addr, &i, AARCH64_INSN_SIZE); > > } > > > > +asm("__static_call_ret: \n" > > + " ret \n") > > + > > This breaks BTI as it lacks the landing pad, and it will be called indirectly. > > > +extern void __static_call_ret(void); > > + > > Better to have an ordinary C function here (with consistent linkage), > but we need to take the address in a way that works with Clang CFI. > > As the two additional instructions are on an ice cold path anyway, I'm > not sure this is an obvious improvement tbh.
If my sums are correct the code block is exactly 32 bytes. So no point saving an instruction. But you could have: .long 1f label: bti c nop/branch ldr x16, 0b br x16 1: bti c ret
That is all self-contained.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |