bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;

  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).