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

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?) We're not
adding yet another scheme/alternative for addressing signed BPF via
separate loader mechanism. Also, if you don't want to use existing
signed BPF infra, then implement it as a policy via BPF LSM + xattr?

   [0] https://lore.kernel.org/bpf/CAADnVQLxgD_7GYWZZ49aY2LqVYOy4uGvK2ikm7MJ1Cj60VPNaw@mail.gmail.com/

Thanks,
Daniel