[PATCH 10/12] libbpf: Embed and verify the metadata hash in the loader

[KP Singh]

On Tue, Jun 10, 2025 at 11:24 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
>
> On Tue, 2025-06-10 at 21:47 +0200, KP Singh wrote:
> > It's been repeatedly mentioned that trusted loaders (whether kernel
> > or BPF programs) are the only way because a large number of BPF
> > use-cases dynamically generate BPF programs.
>
> You keep asserting this, but it isn't supported by patches already

This is supported for sure. But it's not what the patches are
providing a reference implementation for. The patches provide a stand
alone reference implementation using in-kernel / BPF loaders but you
can surely implement this (see below):

> proposed.  Specifically, there already exists a patch set:
>
> https://lore.kernel.org/all/20250528215037.2081066-1-bboscaccy@linux.microsoft.com/

The patch-set takes a very narrow view by adding additional UAPI and
ties us into an implementation. Whereas the current approach keeps the
UAPI clean while still meeting all the use-cases and keeps the
implementation flexible should it need to change. (no tie into the
hash chain approach, if we are able to move to stable BPF instruction
buffers in the future).

Blaise's patches also do not handle the trusted user-space loader
space and the "signature_maps" are not relevant to dynamic generation
or simple BPF programs like networking, see below.

>
> that supports both signed trusted loaders and exact hash chain
> verification of loaders plus program maps.  The core kernel code that

I have mentioned in various replies as to how the current design ends
up working for dynamic loaders. Here's it once again:

* The dynamic userspace loader is trusted, it's either compiled in
with libbpf statically or libbpf is also a trusted library.
* The BPF program is generated and all the relcoations are performed
at runtime, after which the BPF instruction buffer becomes stable and
can be signed which obviates the need for the loader program for
programs that have runtime relocations. And ofcourse, some BPF
programs don't have runtime relocations at all (e.g some networking
programs).
* The program is then signed with a derived credential at runtime and
this signature is passed in attr.signature and this signature is
verified by the kernel.

> does it is only about 10 lines and looks to me like it could easily be
> added to your current patch set.  This means BPF signing could support

I still don't understand the actual reasons for you needing this to
happen in the kernel.

Here's a summary of the reasons that have been thrown around:

Supply chain attacks
================

I got vague answers about supply chain attacks. If one cannot trust
the build environment that builds the BPF programs, has signing keys,
generates and signs the loader, or that builds libbpf / kernel, then I
think one has other issues.

PS: You can also contribute code into LLVM / clang to generate loader
programs directly from a BPF object.

The loader code is hard to understand
=============================

So is the BPF JIT that lives in the kernel, I am sure there are
engineers who understand BPF assembly and JITs? Please remember the
user who uses BPF is different from the user who implements singing
for the BPF users, the latter (e.g. a distro, hyperscalar etc) needs
to be advanced and aware of BPF internals.

"having visibility" in the LSM code
==========================

To implement what specific security policy? There are security
policies and controls that need to be defined that are required by BPF
use-cases and one would expect the LSM experts to help here, none of
them require in kernel verification, here they are:

* LSM controls to reject programs that are not signed
* LSM controls that establish trust on userspace binaries and libraries.
* LSM policies that allow these components to either load programs
signed at runtime using a derived credential.
* LSM policies that allow certain signed BPF programs to be loaded
without requiring elevated privileges i.e CAP_BPF.

Auditing
======

You can surely propose a follow up to my patches that adds audit
logging to the loader, that calls the audit code from using a BPF
kfunc, so this can be extended for auditing.

At this point, I am happy to discuss the actual security policy work
that is needed. For the discussion around the UAPI and in-kernel
verification, I rest it in the hands of the BPF maintainers.


- KP




> signer being in the position of deciding what they want and no loss of
> generality for either use case.
> >  So whatever we build needs to work for everyone and not just your
> > specific use-case or your affinity to an implementation.
>
> The linked patch supports both your trusted loader use case and the
> exact hash chain verification one the security people want.  Your
> current patch only seems to support your use case, which seems a little
> bit counter to the quote above.  However, it also seems that
> reconciling both patch sets to give everyone what they want is easily
> within reach so I think that's what we should all work towards.
>
> Regards,
>
> James
>