From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: KP Singh <kpsingh@kernel.org>
Cc: bpf <bpf@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Blaise Boscaccy <bboscaccy@linux.microsoft.com>,
Paul Moore <paul@paul-moore.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH 10/12] libbpf: Embed and verify the metadata hash in the loader
Date: Mon, 9 Jun 2025 17:08:16 -0700 [thread overview]
Message-ID: <CAADnVQL6jeigFqQqip4JmvCFrdsWGbOFrxREFuD+OOjjaz6JXg@mail.gmail.com> (raw)
In-Reply-To: <20250606232914.317094-11-kpsingh@kernel.org>
On Fri, Jun 6, 2025 at 4:29 PM KP Singh <kpsingh@kernel.org> wrote:
>
> To fulfill the BPF signing contract, represented as Sig(I_loader ||
> H_meta), the generated trusted loader program must verify the integrity
> of the metadata. This signature cryptographically binds the loader's
> instructions (I_loader) to a hash of the metadata (H_meta).
>
> The verification process is embedded directly into the loader program.
> Upon execution, the loader loads the runtime hash from struct bpf_map
> i.e. BPF_PSEUDO_MAP_IDX and compares this runtime hash against an
> expected hash value that has been hardcoded directly by
> bpf_obj__gen_loader.
>
> The load from bpf_map can be improved by calling
> BPF_OBJ_GET_INFO_BY_FD from the kernel context after BPF_OBJ_GET_INFO_BY_FD
> has been updated for being called from the kernel context.
>
> The following instructions are generated:
>
> ld_imm64 r1, const_ptr_to_map // insn[0].src_reg == BPF_PSEUDO_MAP_IDX
> r2 = *(u64 *)(r1 + 0);
> ld_imm64 r3, sha256_of_map_part1 // constant precomputed by
> bpftool (part of H_meta)
> if r2 != r3 goto out;
>
> r2 = *(u64 *)(r1 + 8);
> ld_imm64 r3, sha256_of_map_part2 // (part of H_meta)
> if r2 != r3 goto out;
>
> r2 = *(u64 *)(r1 + 16);
> ld_imm64 r3, sha256_of_map_part3 // (part of H_meta)
> if r2 != r3 goto out;
>
> r2 = *(u64 *)(r1 + 24);
> ld_imm64 r3, sha256_of_map_part4 // (part of H_meta)
> if r2 != r3 goto out;
> ...
>
> Signed-off-by: KP Singh <kpsingh@kernel.org>
> ---
> tools/lib/bpf/bpf_gen_internal.h | 2 ++
> tools/lib/bpf/gen_loader.c | 52 ++++++++++++++++++++++++++++++++
> tools/lib/bpf/libbpf.h | 3 +-
> 3 files changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/bpf_gen_internal.h b/tools/lib/bpf/bpf_gen_internal.h
> index 6ff963a491d9..49af4260b8e6 100644
> --- a/tools/lib/bpf/bpf_gen_internal.h
> +++ b/tools/lib/bpf/bpf_gen_internal.h
> @@ -4,6 +4,7 @@
> #define __BPF_GEN_INTERNAL_H
>
> #include "bpf.h"
> +#include "libbpf_internal.h"
>
> struct ksym_relo_desc {
> const char *name;
> @@ -50,6 +51,7 @@ struct bpf_gen {
> __u32 nr_ksyms;
> int fd_array;
> int nr_fd_array;
> + int hash_insn_offset[SHA256_DWORD_SIZE];
> };
>
> void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps);
> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index 113ae4abd345..3d672c09e948 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -110,6 +110,7 @@ static void emit2(struct bpf_gen *gen, struct bpf_insn insn1, struct bpf_insn in
>
> static int add_data(struct bpf_gen *gen, const void *data, __u32 size);
> static void emit_sys_close_blob(struct bpf_gen *gen, int blob_off);
> +static void bpf_gen__signature_match(struct bpf_gen *gen);
>
> void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps)
> {
> @@ -152,6 +153,8 @@ void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps
> /* R7 contains the error code from sys_bpf. Copy it into R0 and exit. */
> emit(gen, BPF_MOV64_REG(BPF_REG_0, BPF_REG_7));
> emit(gen, BPF_EXIT_INSN());
> + if (gen->opts->gen_hash)
> + bpf_gen__signature_match(gen);
> }
>
> static int add_data(struct bpf_gen *gen, const void *data, __u32 size)
> @@ -368,6 +371,25 @@ static void emit_sys_close_blob(struct bpf_gen *gen, int blob_off)
> __emit_sys_close(gen);
> }
>
> +static int compute_sha_udpate_offsets(struct bpf_gen *gen)
> +{
> + __u64 sha[SHA256_DWORD_SIZE];
> + int i, err;
> +
> + err = libbpf_sha256(gen->data_start, gen->data_cur - gen->data_start, sha);
> + if (err < 0) {
> + pr_warn("sha256 computation of the metadata failed");
> + return err;
> + }
> + for (i = 0; i < SHA256_DWORD_SIZE; i++) {
> + struct bpf_insn *insn =
> + (struct bpf_insn *)(gen->insn_start + gen->hash_insn_offset[i]);
Is there a reason to use offset instead of pointers?
Instead of
int hash_insn_offset[SHA256_DWORD_SIZE];
it could be
struct bpf_insn *hash_insn[SHA256_DWORD_SIZE];
> + insn[0].imm = (__u32)sha[i];
> + insn[1].imm = sha[i] >> 32;
Then above will be gen->hash_insn[i][0].imm ?
> + }
> + return 0;
> +}
> +
> int bpf_gen__finish(struct bpf_gen *gen, int nr_progs, int nr_maps)
> {
> int i;
> @@ -394,6 +416,12 @@ int bpf_gen__finish(struct bpf_gen *gen, int nr_progs, int nr_maps)
> blob_fd_array_off(gen, i));
> emit(gen, BPF_MOV64_IMM(BPF_REG_0, 0));
> emit(gen, BPF_EXIT_INSN());
> + if (gen->opts->gen_hash) {
> + gen->error = compute_sha_udpate_offsets(gen);
> + if (gen->error)
> + return gen->error;
> + }
> +
> pr_debug("gen: finish %s\n", errstr(gen->error));
> if (!gen->error) {
> struct gen_loader_opts *opts = gen->opts;
> @@ -557,6 +585,30 @@ void bpf_gen__map_create(struct bpf_gen *gen,
> emit_sys_close_stack(gen, stack_off(inner_map_fd));
> }
>
> +static void bpf_gen__signature_match(struct bpf_gen *gen)
> +{
> + __s64 off = -(gen->insn_cur - gen->insn_start - gen->cleanup_label) / 8 - 1;
> + int i;
> +
> + for (i = 0; i < SHA256_DWORD_SIZE; i++) {
> + emit2(gen, BPF_LD_IMM64_RAW_FULL(BPF_REG_1, BPF_PSEUDO_MAP_IDX,
> + 0, 0, 0, 0));
> + emit(gen, BPF_LDX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1, i * sizeof(__u64)));
> + gen->hash_insn_offset[i] = gen->insn_cur - gen->insn_start;
and this will be
gen->hash_insn[i] = gen->insn_cur;
next prev parent reply other threads:[~2025-06-10 0:08 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 [this message]
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
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=CAADnVQL6jeigFqQqip4JmvCFrdsWGbOFrxREFuD+OOjjaz6JXg@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--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).