On Thu, Jan 1, 2026 at 1:07 AM Alexei Starovoitov
[off-list ref] wrote:

On Wed, Dec 31, 2025 at 3:21 PM Maciej Żenczykowski [off-list ref] wrote:

quoted

Over the years there's been a number of issues with the eBPF
verifier/jit/codegen (incl. both code bugs & spectre related stuff).

It's an amazing but very complex piece of logic, and I don't think
it's realistic to expect it to ever be (or become) 100% secure.

For example we currently have KASAN reporting buffer length violation
issues on 6.18 (which may or may not be due to eBPF subsystem, but are
worrying none-the-less)

Blocking bpf(BPF_PROG_LOAD, ...) is the only sure fire way to guarantee
the inability to exploit the eBPF subsystem.
In comparison other eBPF operations are pretty benign.
Even map creation is usually at most a memory DoS, furthermore it
remains useful (even with prog load disabled) due to inner maps.

This new sysctl is designed primarily for verified boot systems,
where (while the system is booting from trusted/signed media)
BPF_PROG_LOAD can be enabled, but before untrusted user
media is mounted or networking is enabled, BPF_PROG_LOAD
can be outright disabled.

This provides for a very simple way to limit eBPF programs to only
those signed programs that are part of the verified boot chain,
which has always been a requirement of eBPF use in Android.

I can think of two other ways to accomplish this:
(a) via sepolicy with booleans, but it ends up being pretty complex
    (especially wrt verifying the correctness of the resulting policies)
(b) via BPF_LSM bpf_prog_load hook, which requires enabling additional
    kernel options which aren't necessarily worth the bother,
    and requires dynamically patching the kernel (frowned upon by
    security folks).

This approach appears to simply be the most trivial.

You seem to ignore the existence of sysctl_unprivileged_bpf_disabled.
And with that the CAP_BPF is the only way to prog_load to work.

I am actually aware of it, but we cannot use sysctl_unprivileged_bpf_disabled,
because (last I checked) it disables map creation as well, which we do
want to function
as less privileged (though still partially priv) daemons/users (for
inner map creation)...

Additionally the problem is there is no way to globally block CAP_BPF...
because CAP_SYS_ADMIN (per documentation, and backwards compatibility)
implies it, and that has valid users.

I suspect you're targeting some old kernels.

I don't believe so.  How are you suggesting we globally block BPF_PROG_LOAD,
while there will still be some CAP_SYS_ADMIN processes out of necessity,
and without blocking map creation?