Re: [PATCH bpf] bpf: 'fix' for undefined future potential exploits of BPF_PROG_LOAD

[Alexei Starovoitov]

On Wed, Dec 31, 2025 at 3:21 PM Maciej Żenczykowski <maze@xxxxxxxxxx> wrote:
>
> 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 suspect you're targeting some old kernels.
We're definitely not adding new sysctl because you cannot upgrade
android kernel fast enough.

pw-bot: cr