From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Paul Moore" <paul@paul-moore.com>,
"Daniel Borkmann" <daniel@iogearbox.net>
Cc: <ast@kernel.org>, <kpsingh@kernel.org>,
<James.Bottomley@hansenpartnership.com>,
<bboscaccy@linux.microsoft.com>, <memxor@gmail.com>,
<torvalds@linux-foundation.org>, <a.s.protopopov@gmail.com>,
<bpf@vger.kernel.org>, <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 2/6] bpf: Verify signed loader metadata at load time
Date: Thu, 02 Jul 2026 15:33:04 -0700 [thread overview]
Message-ID: <DJOFY21DYUI4.19WKQ3NPZ4H5R@gmail.com> (raw)
In-Reply-To: <CAHC9VhQD4RHsGiTMVCCTN+eB71-Ueopke8XghExpNJ2PSNa_jQ@mail.gmail.com>
On Thu Jul 2, 2026 at 3:05 PM PDT, Paul Moore wrote:
>
> As I mentioned previously, the security_bpf_prog_load() hook should
> not be moved. Its placement was deliberate, and moving it as you've
> done in this patch creates a security regression.
not true.
> Without this patch,
> for processes where SELinux is preventing BPF programs from being
> loaded, it is able to do so before the process allocates a potentially
> very large chunk of kernel memory, up to one million BPF instructions.
only when signature verification is requested and the hash over insns
is what your hornet thingy did too.
So no regression whatsoever. Exact same behavior.
> With this patch, even in cases where SELinux will prevent the BPF
> program load operation, it is not able to do so before the process
> triggers a potential sizable memory allocation, opening the door for a
> local DoS attack.
Not true either. Worst case is 1M which is 8Mbyte.
Not even close to anything DoS worthy.
> In an effort to work with you on this, I did bring up two alternative
> solutions: a new LSM hook for the signature verification, or the use
> of the existing security_bpf_prog() hook.
Sorry we're not going to add new hook because Paul has
non-technical grudge against bpf.
> While I don't like to do this, you haven't given me much of a choice;
> the security regression can not be ignored:
>
> Nacked-by: Paul Moore (don't move bpf_prog_load LSM hook) <paul@paul-moore.com>
of course. will keep it and let Linus decide during the merge window.
next prev parent reply other threads:[~2026-07-02 22:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 14:35 [PATCH bpf-next v3 0/6] Verify BPF signed loader at load time Daniel Borkmann
2026-07-02 14:36 ` [PATCH bpf-next v3 1/6] bpf: Resolve and cache fd_array objects " Daniel Borkmann
2026-07-02 19:06 ` Anton Protopopov
2026-07-02 21:16 ` Daniel Borkmann
2026-07-02 14:36 ` [PATCH bpf-next v3 2/6] bpf: Verify signed loader metadata " Daniel Borkmann
2026-07-02 22:05 ` Paul Moore
2026-07-02 22:33 ` Alexei Starovoitov [this message]
2026-07-02 14:36 ` [PATCH bpf-next v3 3/6] libbpf: Drop in-loader metadata check for load-time verification Daniel Borkmann
2026-07-02 14:36 ` [PATCH bpf-next v3 4/6] bpftool: Cover loader metadata with the program signature Daniel Borkmann
2026-07-02 14:36 ` [PATCH bpf-next v3 5/6] selftests/bpf: Verify load-time signed loader metadata Daniel Borkmann
2026-07-02 15:17 ` bot+bpf-ci
2026-07-02 15:28 ` Daniel Borkmann
2026-07-02 14:36 ` [PATCH bpf-next v3 6/6] Documentation/bpf: Add BPF signing and enforcement doc Daniel Borkmann
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=DJOFY21DYUI4.19WKQ3NPZ4H5R@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=a.s.protopopov@gmail.com \
--cc=ast@kernel.org \
--cc=bboscaccy@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=paul@paul-moore.com \
--cc=torvalds@linux-foundation.org \
/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