Linux Security Modules development
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: KP Singh <kpsingh@kernel.org>,
	bpf@vger.kernel.org, linux-security-module@vger.kernel.org
Cc: ast@kernel.org, memxor@gmail.com
Subject: Re: [PATCH v2 2/2] bpf, libbpf: reject non-exclusive metadata maps in the signed loader
Date: Fri, 22 May 2026 23:44:32 +0200	[thread overview]
Message-ID: <dcc02e2d-58dd-46eb-9b72-54cd8465fb64@iogearbox.net> (raw)
In-Reply-To: <20260521152217.2345235-3-kpsingh@kernel.org>

On 5/21/26 5:22 PM, KP Singh wrote:
> The loader verifies map->sha against the metadata hash in its
> instructions. map->sha is calculated when BPF_OBJ_GET_INFO_BY_FD is called
> on the frozen map.
> 
> While the map is frozen, the loader must also ensure the map is
> exclusive, as, without exclusivity, another BPF program with map access
> can mutate the contents afterwards, so the check passes on stale data.
> 
> Place excl_prog_sha right after sha[] in struct bpf_map and have
> gen_loader bail with -EINVAL when it is NULL, via BPF_PSEUDO_MAP_IDX at
> fixed offset 32. Declare excl_prog_sha with __bpf_md_ptr so the
> 8-byte BPF_LDX_MEM read works on 32-bit kernels.
> 
> Fixes: fb2b0e290147 ("libbpf: Update light skeleton for signing")
> Signed-off-by: KP Singh <kpsingh@kernel.org>
> ---
>   include/linux/bpf.h                              |  2 +-
>   tools/lib/bpf/gen_loader.c                       | 16 ++++++++++++++++
>   .../selftests/bpf/progs/verifier_map_ptr.c       | 10 ++++++----
>   3 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index cd191c5fdb0a..ea9bd24f82c0 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -295,6 +295,7 @@ struct bpf_map_owner {
>   
>   struct bpf_map {
>   	u8 sha[SHA256_DIGEST_SIZE];
> +	__bpf_md_ptr(char *, excl_prog_sha);
>   	const struct bpf_map_ops *ops;
>   	struct bpf_map *inner_map_meta;
>   #ifdef CONFIG_SECURITY
> @@ -335,7 +336,6 @@ struct bpf_map {
>   	atomic64_t sleepable_refcnt;
>   	s64 __percpu *elem_count;
>   	u64 cookie; /* write-once */
> -	char *excl_prog_sha;
>   };
>   
>   static inline const char *btf_field_type_name(enum btf_field_type type)
> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index 9478b8f78f26..fee35c26deb8 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -600,6 +600,22 @@ static void emit_signature_match(struct bpf_gen *gen)
>   			gen->error = -ERANGE;
>   		}
>   	}
> +
> +	/* Reject if the metadata map is not exclusive. Without exclusivity
> +	 * the cached map->sha[] verified above can be stale: another BPF
> +	 * program with map access could have mutated the contents between
> +	 * BPF_OBJ_GET_INFO_BY_FD and loader execution.
> +	 */

We could probably add sth like this somewhere in the bpf kernel side :

         /* See: emit_signature_match() in tools/lib/bpf/gen_loader.c */
         BUILD_BUG_ON(offsetof(struct bpf_map, sha) != 0);
         BUILD_BUG_ON(offsetof(struct bpf_map, excl_prog_sha) != SHA256_DIGEST_SIZE);
         BUILD_BUG_ON(sizeof_field(struct bpf_map, excl_prog_sha) != sizeof(__u64));

> +	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, SHA256_DWORD_SIZE * sizeof(__u64)));

nit: SHA256_DWORD_SIZE is SHA256_DIGEST_LENGTH / sizeof(__u64), can we just use
      SHA256_DIGEST_LENGTH ?

> +	off = -(gen->insn_cur - gen->insn_start - gen->cleanup_label) / 8 - 2;
> +	if (is_simm16(off)) {
> +		emit(gen, BPF_MOV64_IMM(BPF_REG_7, -EINVAL));
> +		emit(gen, BPF_JMP_IMM(BPF_JEQ, BPF_REG_2, 0, off));
> +	} else {
> +		gen->error = -ERANGE;
> +	}
>   }
>   
>   void bpf_gen__record_attach_target(struct bpf_gen *gen, const char *attach_name,

  parent reply	other threads:[~2026-05-22 21:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-21 15:22 [PATCH v2 0/2] gen_loader fixes KP Singh
2026-05-21 15:22 ` [PATCH v2 1/2] libbpf: fix off-by-one in emit_signature_match jump offset KP Singh
2026-05-21 16:03   ` bot+bpf-ci
2026-05-22 21:21   ` Daniel Borkmann
2026-05-21 15:22 ` [PATCH v2 2/2] bpf, libbpf: reject non-exclusive metadata maps in the signed loader KP Singh
2026-05-21 16:03   ` bot+bpf-ci
2026-05-22 21:44   ` Daniel Borkmann [this message]
2026-05-22 22:05     ` Daniel Borkmann

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=dcc02e2d-58dd-46eb-9b72-54cd8465fb64@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=memxor@gmail.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