linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: KP Singh <kpsingh@kernel.org>
Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
	bboscaccy@linux.microsoft.com, paul@paul-moore.com,
	kys@microsoft.com, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org
Subject: Re: [PATCH 00/12] Signed BPF programs
Date: Tue, 10 Jun 2025 11:45:43 +0200	[thread overview]
Message-ID: <87cybcdj5k.fsf@toke.dk> (raw)
In-Reply-To: <CACYkzJ6_VXiWauPBMWOzX+QHedj4noYxfmt_usUzXCiifuEuLA@mail.gmail.com>

KP Singh <kpsingh@kernel.org> writes:

> On Mon, Jun 9, 2025 at 10:20 AM Toke Høiland-Jørgensen <toke@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
maybe it just means "some userspace binaries need to be exempt from any
signing requirement"? Or am I missing something?

-Toke

  reply	other threads:[~2025-06-10  9:45 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-06 23:29 [PATCH 00/12] Signed BPF programs KP Singh
2025-06-06 23:29 ` [PATCH 01/12] bpf: Implement an internal helper for SHA256 hashing KP Singh
2025-06-09  9:31   ` kernel test robot
2025-06-09 16:56   ` Alexei Starovoitov
2025-06-12 19:07   ` Eric Biggers
2025-06-16 23:40     ` KP Singh
2025-06-16 23:48       ` Eric Biggers
2025-06-17  0:04         ` KP Singh
2025-06-06 23:29 ` [PATCH 02/12] bpf: Update the bpf_prog_calc_tag to use SHA256 KP Singh
2025-06-09 17:46   ` Alexei Starovoitov
2025-06-06 23:29 ` [PATCH 03/12] bpf: Implement exclusive map creation KP Singh
2025-06-09 20:58   ` Alexei Starovoitov
2025-06-11 21:44     ` KP Singh
2025-06-11 22:55       ` Alexei Starovoitov
2025-06-11 23:05         ` KP Singh
2025-06-06 23:29 ` [PATCH 04/12] libbpf: Implement SHA256 internal helper KP Singh
2025-06-12 22:55   ` Andrii Nakryiko
2025-06-06 23:29 ` [PATCH 05/12] libbpf: Support exclusive map creation KP Singh
2025-06-07  9:16   ` kernel test robot
2025-06-12 22:55   ` Andrii Nakryiko
2025-06-12 23:41     ` KP Singh
2025-06-13 16:51       ` Andrii Nakryiko
2025-07-12  0:50         ` KP Singh
2025-07-12  0:53     ` KP Singh
2025-07-14 20:56       ` Andrii Nakryiko
2025-07-14 12:29     ` KP Singh
2025-07-14 12:55       ` KP Singh
2025-07-14 21:05         ` Andrii Nakryiko
2025-06-06 23:29 ` [PATCH 06/12] selftests/bpf: Add tests for exclusive maps KP Singh
2025-06-06 23:29 ` [PATCH 07/12] bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD KP Singh
2025-06-07  9:26   ` kernel test robot
2025-06-08 13:11   ` kernel test robot
2025-06-09 21:30   ` Alexei Starovoitov
2025-06-11 14:27     ` KP Singh
2025-06-11 15:04       ` Alexei Starovoitov
2025-06-11 16:05         ` KP Singh
2025-06-06 23:29 ` [PATCH 08/12] bpf: Implement signature verification for BPF programs KP Singh
2025-06-09 21:39   ` Alexei Starovoitov
2025-06-10 16:37   ` Blaise Boscaccy
2025-06-06 23:29 ` [PATCH 09/12] libbpf: Update light skeleton for signing KP Singh
2025-06-09 21:41   ` Alexei Starovoitov
2025-06-06 23:29 ` [PATCH 10/12] libbpf: Embed and verify the metadata hash in the loader KP Singh
2025-06-10  0:08   ` Alexei Starovoitov
2025-06-10 16:51   ` Blaise Boscaccy
2025-06-10 17:43     ` KP Singh
2025-06-10 18:15       ` Blaise Boscaccy
2025-06-10 19:47         ` KP Singh
2025-06-10 21:24           ` James Bottomley
2025-06-10 22:31             ` Paul Moore
2025-06-10 22:35             ` KP Singh
2025-06-11 11:59               ` James Bottomley
2025-06-11 12:33                 ` KP Singh
2025-06-11 13:12                   ` James Bottomley
2025-06-11 13:24                     ` KP Singh
2025-06-11 13:18                   ` James Bottomley
2025-06-11 13:41                     ` KP Singh
2025-06-11 14:43                       ` James Bottomley
2025-06-11 14:45                         ` KP Singh
2025-06-10 20:56         ` KP Singh
2025-06-12 22:56   ` Andrii Nakryiko
2025-06-06 23:29 ` [PATCH 11/12] bpftool: Add support for signing BPF programs KP Singh
2025-06-08 14:03   ` James Bottomley
2025-06-10  8:50     ` KP Singh
2025-06-10 15:56       ` James Bottomley
2025-06-10 16:41         ` KP Singh
2025-06-10 16:34       ` Blaise Boscaccy
2025-06-06 23:29 ` [PATCH 12/12] selftests/bpf: Enable signature verification for all lskel tests KP Singh
2025-06-10  0:45   ` Alexei Starovoitov
2025-06-10 16:39   ` Blaise Boscaccy
2025-06-10 16:42     ` KP Singh
2025-06-09  8:20 ` [PATCH 00/12] Signed BPF programs Toke Høiland-Jørgensen
2025-06-09 11:40   ` KP Singh
2025-06-10  9:45     ` Toke Høiland-Jørgensen [this message]
2025-06-10 11:18       ` KP Singh
2025-06-10 11:58         ` Toke Høiland-Jørgensen
2025-06-10 12:26           ` KP Singh
2025-06-10 14:25             ` Toke Høiland-Jørgensen
2025-07-08 15:15 ` Blaise Boscaccy
2025-07-10 14:49   ` KP Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cybcdj5k.fsf@toke.dk \
    --to=toke@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bboscaccy@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).