[PATCH 00/12] Signed BPF programs

[Toke Høiland-Jørgensen]

KP Singh <kpsingh at kernel.org> writes:

> On Tue, Jun 10, 2025 at 11:45 AM Toke Høiland-Jørgensen <toke at kernel.org> wrote:
>>
>> KP Singh <kpsingh at kernel.org> writes:
>>
>> > On Mon, Jun 9, 2025 at 10:20 AM Toke Høiland-Jørgensen <toke at kernel.org> wrote:
>> >>
>> >>
>> >> > Given that many use-cases (e.g. Cilium) generate trusted BPF programs,
>> >> > trusted loaders are an inevitability and a requirement for signing support, a
>> >> > entrusting loader programs will be a fundamental requirement for an security
>> >> > policy.
>> >>
>> >> So I've been following this discussion a bit on the sidelines, and have
>> >> a question related to this:
>> >>
>> >> From your description a loader would have embedded hashes for a concrete
>> >> BPF program, which doesn't really work for dynamically generated
>> >> programs. So how would a "trusted loader" work for dynamically generated
>> >> programs?
>> >
>> > The trusted loader for dynamically generated programs would be the
>> > binary that loads the BPF program. So a security policy will need to
>> > allow certain trusted binaries (signed with a different key) to load
>> > unsigned BPF programs for cilium.
>>
>> OK, so this refers to a policy along the line of: "Only allow signed BPF
>> program except for this particular userspace binary that is allowed to
>> load anything"?
>>
>> > For a stronger policy, the generators can use a derived key and
>> > identity (e.g from the Kubernetes / machine / TLS certificate) and
>> > then sign their programs using this certificate. The LSM policy then
>> > allows verification with a trusted build key and for certain binaries,
>> > with the delegated credentials.
>>
>> And this means "add a separate trusted key on the kernel side that the
>> userspace binary signs things with before passing it to the kernel"?
>>
>> In which case, how does that tie into the original statement I quoted at
>> the top of this email? The "trusted loaders are an inevitability" bit? I
>> was assuming that the "trusted loaders" in that sentence referred to the
>> light-skeleton loader program, but from your reply I'm not thinking
>
> No trusted loaders are exactly what they mean, trusted blobs of code
> that can load BPF programs, these can be loader programs in light
> skeletons or trusted user-space binaries.

Right, but this patch series has no mechanism for establishing a
userspace loader binary as trusted (right?). The paragraph I quoted
makes it sound like these are related, and I was trying to figure out
what the relation was. But it sounds like the answer is that they are
not?

-Toke