From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <kees@kernel.org>
Cc: Jennifer Miller <jmill@asu.edu>,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com,
linux-hardening@vger.kernel.org, xmei5@asu.edu,
samitolvanen@google.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 1/1] bpf: Enable JIT hardening by default when x86_64 CFI is enabled
Date: Mon, 10 Aug 2026 10:02:07 +0200 [thread overview]
Message-ID: <20260810080207.GD1642880@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <202608091030.C69278022@keescook>
On Sun, Aug 09, 2026 at 10:30:35AM -0700, Kees Cook wrote:
> On Fri, Jul 10, 2026 at 12:19:32PM -0700, Jennifer Miller wrote:
> > Initializes bpf_jit_harden to 1 if x86_64 CFI is enabled. Prevents the
> > misuse of BPF JIT code to craft CFI signatures or Endbr64 instructions
> > by enabling constant blinding for JITted BPF code from unprivileged
> > users.
> >
> > Signed-off-by: Jennifer Miller <jmill@asu.edu>
> > ---
> > kernel/bpf/core.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 47fe047ad30b..ed22b90c6e4e 100644
> > --- 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.
> > + */
> > +int bpf_jit_harden __read_mostly = IS_ENABLED(CONFIG_X86_64) &&
> > + IS_ENABLED(CONFIG_CFI);
>
> Why not just do this for all CONFIG_CFI?
Additionally; does it make sense to add an arch hook to
bpf_jit_blind_constant() / bpg_jit_blind_insn() such that architectures
can blacklist certain values?
Because as is, the whole thing *can* still generate an ENBBR by sheer
accident.
I'm thinking something simple like:
while (imm_rnd ^ imm == gen_endbr() || imm_rnd == gen_endbr())
imm_rnd = get_random_u32();
should do.
prev parent reply other threads:[~2026-08-10 8:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 19:19 [RFC PATCH bpf-next v1 0/1] Enable BPF JIT hardening by default when x86_64 CFI is enabled Jennifer Miller
2026-07-10 19:19 ` [RFC PATCH bpf-next v1 1/1] bpf: Enable " Jennifer Miller
2026-07-12 6:22 ` bot+bpf-ci
2026-08-09 17:30 ` Kees Cook
2026-08-10 8:02 ` Peter Zijlstra [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=20260810080207.GD1642880@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jmill@asu.edu \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=samitolvanen@google.com \
--cc=xmei5@asu.edu \
/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