lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABCJKued2XsLp5+ZW1ZWQn6=CgYkhjEDyJdfTRTR1MGkvDtmXg@mail.gmail.com>
Date: Fri, 11 Jul 2025 11:49:29 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Will Deacon <will@...nel.org>
Cc: bpf@...r.kernel.org, Puranjay Mohan <puranjay@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Catalin Marinas <catalin.marinas@....com>, Andrii Nakryiko <andrii@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, Maxwell Bland <mbland@...orola.com>, 
	Puranjay Mohan <puranjay12@...il.com>, Dao Huang <huangdao1@...o.com>
Subject: Re: [PATCH bpf-next v9 2/2] arm64/cfi,bpf: Support kCFI + BPF on arm64

Hi Will,

On Fri, Jul 11, 2025 at 7:26 AM Will Deacon <will@...nel.org> wrote:
>
> On Mon, May 05, 2025 at 10:34:40PM +0000, Sami Tolvanen wrote:
> > From: Puranjay Mohan <puranjay12@...il.com>
> >
> > Currently, bpf_dispatcher_*_func() is marked with `__nocfi` therefore
> > calling BPF programs from this interface doesn't cause CFI warnings.
> >
> > When BPF programs are called directly from C: from BPF helpers or
> > struct_ops, CFI warnings are generated.
> >
> > Implement proper CFI prologues for the BPF programs and callbacks and
> > drop __nocfi for arm64. Fix the trampoline generation code to emit kCFI
> > prologue when a struct_ops trampoline is being prepared.
> >
> > Signed-off-by: Puranjay Mohan <puranjay12@...il.com>
> > Co-developed-by: Maxwell Bland <mbland@...orola.com>
> > Signed-off-by: Maxwell Bland <mbland@...orola.com>
> > Co-developed-by: Sami Tolvanen <samitolvanen@...gle.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@...gle.com>
> > Tested-by: Dao Huang <huangdao1@...o.com>
> > ---
> >  arch/arm64/include/asm/cfi.h    | 23 +++++++++++++++++++++++
> >  arch/arm64/kernel/alternative.c | 25 +++++++++++++++++++++++++
> >  arch/arm64/net/bpf_jit_comp.c   | 22 +++++++++++++++++++---
> >  3 files changed, 67 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm64/include/asm/cfi.h
> >
> > diff --git a/arch/arm64/include/asm/cfi.h b/arch/arm64/include/asm/cfi.h
> > new file mode 100644
> > index 000000000000..670e191f8628
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/cfi.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_ARM64_CFI_H
> > +#define _ASM_ARM64_CFI_H
> > +
> > +#ifdef CONFIG_CFI_CLANG
> > +#define __bpfcall
> > +static inline int cfi_get_offset(void)
> > +{
> > +     return 4;
>
> Needs a comment.

Ack.

> > +}
> > +#define cfi_get_offset cfi_get_offset
> > +extern u32 cfi_bpf_hash;
> > +extern u32 cfi_bpf_subprog_hash;
> > +extern u32 cfi_get_func_hash(void *func);
> > +#else
> > +#define cfi_bpf_hash 0U
> > +#define cfi_bpf_subprog_hash 0U
> > +static inline u32 cfi_get_func_hash(void *func)
> > +{
> > +     return 0;
> > +}
> > +#endif /* CONFIG_CFI_CLANG */
> > +#endif /* _ASM_ARM64_CFI_H */
>
> This looks like an awful lot of boiler plate to me. The only thing you
> seem to need is the CFI offset -- why isn't that just a constant that we
> can define (or a Kconfig symbol?).

The cfi_get_offset function was originally added in commit
4f9087f16651 ("x86/cfi,bpf: Fix BPF JIT call") because the offset can
change on x86 depending on which CFI scheme is enabled at runtime.
Starting with commit 2cd3e3772e41 ("x86/cfi,bpf: Fix bpf_struct_ops
CFI") the function is also called by the generic BPF code, so we can't
trivially replace it with a constant. However, since this defaults to
`4` unless the architecture adds pre-function NOPs, I think we could
simply move the default implementation to include/linux/cfi.h (and
also drop the RISC-V version). Come to think of it, we could probably
move most of this boilerplate to generic code. I'll refactor this and
send a new version.

> > diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> > index 8ff6610af496..71c153488dad 100644
> > --- a/arch/arm64/kernel/alternative.c
> > +++ b/arch/arm64/kernel/alternative.c
> > @@ -8,11 +8,13 @@
> >
> >  #define pr_fmt(fmt) "alternatives: " fmt
> >
> > +#include <linux/cfi_types.h>
> >  #include <linux/init.h>
> >  #include <linux/cpu.h>
> >  #include <linux/elf.h>
> >  #include <asm/cacheflush.h>
> >  #include <asm/alternative.h>
> > +#include <asm/cfi.h>
> >  #include <asm/cpufeature.h>
> >  #include <asm/insn.h>
> >  #include <asm/module.h>
> > @@ -298,3 +300,26 @@ noinstr void alt_cb_patch_nops(struct alt_instr *alt, __le32 *origptr,
> >               updptr[i] = cpu_to_le32(aarch64_insn_gen_nop());
> >  }
> >  EXPORT_SYMBOL(alt_cb_patch_nops);
> > +
> > +#ifdef CONFIG_CFI_CLANG
> > +struct bpf_insn;
> > +
> > +/* Must match bpf_func_t / DEFINE_BPF_PROG_RUN() */
> > +extern unsigned int __bpf_prog_runX(const void *ctx,
> > +                                 const struct bpf_insn *insn);
> > +DEFINE_CFI_TYPE(cfi_bpf_hash, __bpf_prog_runX);
> > +
> > +/* Must match bpf_callback_t */
> > +extern u64 __bpf_callback_fn(u64, u64, u64, u64, u64);
> > +DEFINE_CFI_TYPE(cfi_bpf_subprog_hash, __bpf_callback_fn);
> > +
> > +u32 cfi_get_func_hash(void *func)
> > +{
> > +     u32 hash;
> > +
> > +     if (get_kernel_nofault(hash, func - cfi_get_offset()))
> > +             return 0;
> > +
> > +     return hash;
> > +}
> > +#endif /* CONFIG_CFI_CLANG */
>
> I don't think this should be in alternative.c. It's probably better off
> either as a 'static inline' in the new cfi.h header.

Sure, I'll find a better place for this. RISC-V again seems to have
the exact same function, so I think a __weak implementation in
kernel/cfi.c would work here, allowing x86 to still conveniently
override the function.

> > diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> > index 70d7c89d3ac9..3b3691e88dd5 100644
> > --- a/arch/arm64/net/bpf_jit_comp.c
> > +++ b/arch/arm64/net/bpf_jit_comp.c
> > @@ -9,6 +9,7 @@
> >
> >  #include <linux/bitfield.h>
> >  #include <linux/bpf.h>
> > +#include <linux/cfi.h>
> >  #include <linux/filter.h>
> >  #include <linux/memory.h>
> >  #include <linux/printk.h>
> > @@ -164,6 +165,12 @@ static inline void emit_bti(u32 insn, struct jit_ctx *ctx)
> >               emit(insn, ctx);
> >  }
> >
> > +static inline void emit_kcfi(u32 hash, struct jit_ctx *ctx)
> > +{
> > +     if (IS_ENABLED(CONFIG_CFI_CLANG))
> > +             emit(hash, ctx);
> > +}
> > +
> >  /*
> >   * Kernel addresses in the vmalloc space use at most 48 bits, and the
> >   * remaining bits are guaranteed to be 0x1. So we can compose the address
> > @@ -474,7 +481,6 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
> >       const bool is_main_prog = !bpf_is_subprog(prog);
> >       const u8 fp = bpf2a64[BPF_REG_FP];
> >       const u8 arena_vm_base = bpf2a64[ARENA_VM_START];
> > -     const int idx0 = ctx->idx;
> >       int cur_offset;
> >
> >       /*
> > @@ -500,6 +506,9 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
> >        *
> >        */
> >
> > +     emit_kcfi(is_main_prog ? cfi_bpf_hash : cfi_bpf_subprog_hash, ctx);
> > +     const int idx0 = ctx->idx;
> > +
> >       /* bpf function may be invoked by 3 instruction types:
> >        * 1. bl, attached via freplace to bpf prog via short jump
> >        * 2. br, attached via freplace to bpf prog via long jump
> > @@ -2009,9 +2018,9 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> >               jit_data->ro_header = ro_header;
> >       }
> >
> > -     prog->bpf_func = (void *)ctx.ro_image;
> > +     prog->bpf_func = (void *)ctx.ro_image + cfi_get_offset();
> >       prog->jited = 1;
> > -     prog->jited_len = prog_size;
> > +     prog->jited_len = prog_size - cfi_get_offset();
>
> Why do we add the offset even when CONFIG_CFI_CLANG is not enabled?

The function returns zero if CFI is not enabled, so I believe it's
just to avoid extra if (IS_ENABLED(CONFIG_CFI_CLANG)) statements in
the code. IMO this is cleaner, but I can certainly change this if you
prefer.

Thanks for taking a look!

Sami

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ