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

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Aug 17, 2026 at 06:11:10PM +0200, Daniel Borkmann 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.

BPF made the mistake of using X.509 and PKCS#7 again, but that doesn't
mean it wasn't a mistake.  These formats are highly complex, with each
"signature" actually being an ASN.1 object containing multiple
certificates and signatures for arbitrary algorithms, and many other
unnecessary complexities.  The kernel's X.509, PKCS#7, and ASN.1 code
has had regular bugs ever since it was added to the kernel over a decade
ago.  Just in the last week two more vulnerabilities have gone by:
https://lore.kernel.org/all/20260821192502.3942767-2-Jeremy.Jean@oss.cyber.gouv.fr/
and
https://lore.kernel.org/all/20260822212703.1019792-2-Jeremy.Jean@oss.cyber.gouv.fr/

Just because it's not in the BPF subsystem doesn't mean it's not BPF's
responsibility for choosing to depend on this unsupportable code.

I've mostly given up even trying to review X.509 and PKCS#7 kernel
patches, as they are difficult to understand and have little to do with
actual cryptography.  And anyone building a secure system shouldn't be
using them anyway.  It's nearly impossible to implement these data
formats correctly; it's best left for userspace libraries that
absolutely *have* to support these formats and have better testing and
fuzzing tools available.

These formats are not necessary to do signatures either, as the
signature algorithms can just be used directly, e.g.
https://docs.kernel.org/crypto/libcrypto-signature.html#ml-dsa

But in most cases module authentication has never needed signatures in
the first place, as either hash-based authentication
(https://lore.kernel.org/linux-modules/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net/)
could be used, or modules can be trusted based on being loaded from a
filesystem that is already authenticated itself.

We should start moving on from the mistake of building X.509 and PKCS#7
based systems in the kernel.  It's not working.

If there is a use case for authenticating BPF programs based on where
they are loaded from, that seems very reasonable to support directly
instead of forcing the use of unnecessary signatures and data formats.

- Eric