Re: [RFC PATCH bpf-next v1 1/1] bpf: Enable JIT hardening by default when x86_64 CFI is enabled

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Initializing `bpf_jit_harden` to `1` by default provides incomplete CFI protection (exempting CAP_BPF users) while unconditionally breaking BPF observability for all users.
- [High] `bpf_jit_harden` is not enabled by default for `CONFIG_X86_KERNEL_IBT` without `CONFIG_CFI`, leaving Endbr64 instructions unprotected against crafted constants.
- [Low] The newly added multi-line comment violates BPF subsystem style guidelines.
--

--- Patch [1]: [RFC PATCH bpf-next v1 1/1] bpf: Enable JIT hardening by default when x86_64 CFI is enabled ---
commit 977257fbaf53ef7b4278e0a06c6f26b8addb7fac
Author: Jennifer Miller <jmill@asu.edu>

bpf: Enable JIT hardening by default when x86_64 CFI is enabled

This commit initializes bpf_jit_harden to 1 by default when x86_64 CFI is
enabled. It aims to prevent unprivileged users from crafting CFI signatures
or Endbr64 instructions by enabling constant blinding for JITted BPF code.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -548,7 +548,11 @@ void bpf_prog_kallsyms_del_all(struct bpf_prog *fp)
>  /* All BPF JIT sysctl knobs here. */
>  int bpf_jit_enable   __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);
>  int bpf_jit_kallsyms __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_DEFAULT_ON);
> -int bpf_jit_harden   __read_mostly;
> +/* Enable hardening by default when x86_64 CFI is enabled to prevent CFI
> + * hashes and endbr64 instructions from being crafted.
> + */

[Severity: Low]
This isn't a bug, but does this multi-line comment follow the BPF subsystem
formatting rules? The guidelines require the opening slash and asterisk to
be on a line by themselves for multi-line comments.

> +int bpf_jit_harden   __read_mostly = IS_ENABLED(CONFIG_X86_64) &&
> +					IS_ENABLED(CONFIG_CFI);

[Severity: High]
Does initializing bpf_jit_harden to 1 using boolean evaluation create an
issue with observability for privileged users?

Looking at include/linux/filter.h in bpf_jit_kallsyms_enabled(), any
non-zero value for bpf_jit_harden disables kallsyms:

if (bpf_jit_harden)
        return false;

However, looking at bpf_jit_blinding_enabled() in the same file, a value
of 1 explicitly bypasses blinding for users with CAP_BPF:

if (bpf_jit_harden == 1 && bpf_token_capable(prog->aux->token, CAP_BPF))
        return false;

Will this result in breaking BPF observability like profiling and stack
traces for all users, while simultaneously failing to provide the security
benefit of constant blinding for privileged users? Should this be set to 2
instead?

[Severity: High]
Also, does gating this mitigation exclusively on CONFIG_CFI leave Endbr64
instructions unprotected?

The commit message mentions preventing endbr64 instructions from being
crafted, but endbr64 is tied to hardware Indirect Branch Tracking (IBT)
which uses CONFIG_X86_KERNEL_IBT.

If a kernel is compiled with IBT enabled but CONFIG_CFI disabled, the
boolean logic will evaluate to 0, leaving the JIT vulnerable to 32-bit
constants corresponding to endbr64 gadgets.

Should CONFIG_X86_KERNEL_IBT be included in this evaluation to fully cover
the protections mentioned in the commit message?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710191932.120911-2-jmill@asu.edu?part=1