[PATCH 0/3] BPF signature verification

[KP Singh]

On Sat, May 31, 2025 at 12:27 AM Blaise Boscaccy
<bboscaccy at linux.microsoft.com> wrote:
>
> KP Singh <kpsingh at kernel.org> writes:
>
> > On Sat, May 31, 2025 at 12:14 AM Blaise Boscaccy
> > <bboscaccy at linux.microsoft.com> wrote:
> >>
> >> KP Singh <kpsingh at kernel.org> writes:
> >>
> >> > On Fri, May 30, 2025 at 11:19 PM Blaise Boscaccy
> >> > <bboscaccy at linux.microsoft.com> wrote:
> >> >>
> >> >> KP Singh <kpsingh at kernel.org> writes:
> >> >>
> >> >
> >> > [...]
> >> >
> >> >> >
> >> >>
> >> >> And that isn't at odds with the kernel being able to do it nor is it
> >> >> with what I posted.
> >> >>
> >> >> > If your build environment that signs the BPF program is compromised
> >> >> > and can inject arbitrary code, then signing does not help.  Can you
> >> >> > explain what a supply chain attack would look like here?
> >> >> >
> >> >>
> >> >> Most people here can read C code. The number of people that can read
> >> >> ebpf assembly metaprogramming code is much smaller. Compromising clang
> >> >> is one thing, compromising libbpf is another. Your proposal increases
> >> >> the attack surface with no observable benefit. If I was going to leave a
> >> >> hard-to-find backdoor into ring0, gen.c would be a fun place to explore
> >> >> doing it. Module and UEFI signature verification code doesn't live
> >> >> inside of GCC or Clang as set of meta-instructions that get emitted, and
> >> >> there are very good reasons for that.
> >> >>
> >> >> Further, since the signature verification code is unique for each and
> >> >> every program it needs to be verified/proved/tested for each and every
> >> >> program. Additionally, since all these checks are being forced outside
> >> >> of the kernel proper, with the insistence of keeping the LSM layer in
> >> >> the dark of the ultimate result, the only way to test that a program
> >> >> will fail if the map is corrupted is to physically corrupt each and
> >> >> every program and test that individually. That isn't "elegant" nor "user
> >> >> friendly" in any way, shape or form.
> >> >>
> >> >> >> subsystem.  Additionally, it is impossible to verify the code
> >> >> >> performing the signature verification, as it is uniquely regenerated
> >> >> >
> >> >> > The LSM needs to ensure that it allows trusted LOADER programs i.e.
> >> >> > with signatures and potentially trusted signed user-space binaries
> >> >> > with unsigned or delegated signing (this will be needed for Cilium and
> >> >> > bpftrace that dynamically generate BPF programs), that's a more
> >> >> > important aspect of the LSM policy from a BPF perspective.
> >> >> >
> >> >>
> >> >> I would like to be able to sign my programs please and have the kernel
> >> >> verify it was done correctly. Why are you insisting that I *don't* do
> >> >> that?  I'm yet to see any technical objection to doing that. Do you have
> >> >> one that you'd like to share at this point?
> >> >
> >> > The kernel allows a trusted loader that's signed with your private
> >> > key, that runs in the kernel context to delegate the verification.
> >> > This pattern of a trusted / delegated loader is going to be required
> >> > for many of the BPF use-cases that are out there (Cilium, bpftrace)
> >> > that dynamically generate eBPF programs.
> >> >
> >> > The technical objection is that:
> >> >
> >> > * It does not align with most BPF use-cases out there as most
> >> > use-cases need a trusted loader.
> >>
> >> No, it's definitely a use case. It's trivial to support both a trusted
> >> loader and a signature over the hash chain of supplied assets.
> >>
> >> > * Locks us into a UAPI, whereas a signed LOADER allows us to
> >> > incrementally build signing for all use-cases without compromising the
> >> > security properties.
> >> >
> >>
> >> Your proposal locks us into a UAPI as well. There is no way to make to
> >> do this via UAPI without making a UAPI design choice.
> >>
> >> > BPF's philosophy is that of flexibility and not locking the users into
> >> > a rigid in-kernel implementation and UAPI.
> >> >
> >>
> >> Then why are you locking us into a rigid
> >> only-signing-the-loader-is-allowed implementation?
> >
> > I explained this before, the delegated / trusted loader is needed by
> > many BPF use-cases. A UAPI is forever, thus the lock-in.
> >
>
> Again, I'm not following. What is technically wrong with supporting both
> signing a loader only and allowing for the signature of multiple
> passed-in assets? It's trivial to support both and any path forward will
> force a UAPI lock-in.
>
> Do you simply feel that it isn't a valid use case and therefore we
> shouldn't be allowed to do it?
>

I am saying both are not needed when one (trusted loader) handles all
cases. You are writing / generating the loader anyways, you have the
private key, the only thing to be done is add a few lines to the
loader to verify an embedded hash.

Let's have this discussion in the patch series, much easier to discuss
with the code.