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

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.

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.

-Toke