KP Singh [off-list ref] writes:

On Tue, Jun 10, 2025 at 11:45 AM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

KP Singh [off-list ref] writes:

quoted

On Mon, Jun 9, 2025 at 10:20 AM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

quoted

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"?

quoted

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