Re: [PATCH bpf-next 0/5] bpf: Introduce LOADER_LOAD_FD

[Thiébaud Weksteen]

On Tue, Aug 18, 2026 at 2:11 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> On 8/13/26 2:26 AM, Thiébaud Weksteen wrote:
> > The bpf subsystem supports a signed-bpf infrastructure to guarantee the
> > authenticity of programs [1, 2]. While this infrastructure is ideal for
> > dynamic environments or enterprise deployments where untrusted binaries
> > are loaded post-boot, it introduces unnecessary complexity for static
> > platform use cases.
> >
> > In the Android ecosystem, platform BPF programs reside exclusively on
> > read-only partitions that are strictly verified at the block level via
> > dm-verity. Because the kernel has already guaranteed the authenticity of
> > the underlying file, parsing and validating a secondary signature inside
> > the BPF subsystem is redundant, complex (because it requires X509 and
> > PKCS#7 parsing) and necessitates introducing additional signing flows
> > during build.
>
> Note that the BPF subsys doesn't implement any X.509 or PKCS#7 parsing,
> rather we reuse the same mechanism as the module loader has been using.
>
> > Furthermore, relying on signatures forces the kernel to manage a
> > dedicated public key keyring. In a decentralized ecosystem comprising
> > various OEMs and SoC vendors, managing these keys specifically for
> > infrastructure BPF programs presents an operational hurdle.
>
> There is no dedicated BPF keyring.. an OEM key built into a kernel image
> has no additional runtime key management.
>
> > Thanks to light skeletons, it is possible to embed the loading steps
> > within a wrapping BPF program (also known as loader). In turns, the
> > loading of the loader only requires a limited, well-defined number of
> > steps. This series introduces the bpf command LOADER_LOAD_FD for the
> > kernel to directly load an ELF file which contains a loader with its
> > data. By moving the loading within the kernel, the authenticity of the
> > loader and its content can be guaranteed by existing kernel mechanisms.
>
> Same issue still holds as described in [0]. Also, this sounds more like
> convenience for Android offloaded to the kernel.. (you stated redundant
> given the signature validation and complexity wrt keyring.. so what?
> don't you have the latter anyway for vendor kernel modules?)

Thanks for the feedback Daniel.

Vendor kernel modules are verified as described in the 'precedent'
section: there are no signatures per module. Instead the combination
of dm-verity and SELinux policy ensures the modules' authenticity.

> We're not
> adding yet another scheme/alternative for addressing signed BPF via
> separate loader mechanism.

I understand your position. Thanks for taking the time to reply.