From: Eduard Zingerman <eddyz87@gmail.com>
To: Anton Protopopov <a.s.protopopov@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Anton Protopopov <aspsk@isovalent.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Quentin Monnet <qmo@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>
Subject: Re: [RFC bpf-next 5/9] bpf, x86: add support for indirect jumps
Date: Wed, 18 Jun 2025 04:03:55 -0700 [thread overview]
Message-ID: <8727a800569d88f8f932333859590f702c5332ea.camel@gmail.com> (raw)
In-Reply-To: <20250615085943.3871208-6-a.s.protopopov@gmail.com>
On Sun, 2025-06-15 at 08:59 +0000, Anton Protopopov wrote:
[...]
> 0: r3 = r1 # "switch (r3)"
> 1: if r3 > 0x13 goto +0x666 # check r3 boundaries
> 2: r3 <<= 0x3 # r3 is void*, point to an address
> 3: r1 = 0xbeef ll # r1 is PTR_TO_MAP_VALUE, r1->map_ptr=M
> 5: r1 += r3 # r1 inherits boundaries from r3
> 6: r1 = *(u64 *)(r1 + 0x0) # r1 now has type INSN_TO_PTR
^^^^^^^^^^^
PTR_TO_INSN?
> 7: gotox r1[,imm=fd(M)] # verifier checks that M == r1->map_ptr
[...]
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 37dc83d91832..d20f6775605d 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -2520,6 +2520,13 @@ st: if (is_imm8(insn->off))
>
> break;
>
> + case BPF_JMP | BPF_JA | BPF_X:
> + case BPF_JMP32 | BPF_JA | BPF_X:
Is it necessary to add both JMP and JMP32 versions?
Do we need to extend e.g. bpf_jit_supports_insn() and report an error
in verifier.c or should we rely on individual jits to report unknown
instruction?
> + emit_indirect_jump(&prog,
> + reg2hex[insn->dst_reg],
> + is_ereg(insn->dst_reg),
> + image + addrs[i - 1]);
> + break;
> case BPF_JMP | BPF_JA:
> case BPF_JMP32 | BPF_JA:
> if (BPF_CLASS(insn->code) == BPF_JMP) {
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 008bcd44c60e..3c5eaea2b476 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -952,6 +952,7 @@ enum bpf_reg_type {
> PTR_TO_ARENA,
> PTR_TO_BUF, /* reg points to a read/write buffer */
> PTR_TO_FUNC, /* reg points to a bpf program function */
> + PTR_TO_INSN, /* reg points to a bpf program instruction */
> CONST_PTR_TO_DYNPTR, /* reg points to a const struct bpf_dynptr */
> __BPF_REG_TYPE_MAX,
>
> @@ -3601,6 +3602,7 @@ int bpf_insn_set_ready(struct bpf_map *map);
> void bpf_insn_set_release(struct bpf_map *map);
> void bpf_insn_set_adjust(struct bpf_map *map, u32 off, u32 len);
> void bpf_insn_set_adjust_after_remove(struct bpf_map *map, u32 off, u32 len);
> +int bpf_insn_set_iter_xlated_offset(struct bpf_map *map, u32 iter_no);
This is a horrible name:
- this function is not an iterator;
- it is way too long.
Maybe make it a bit more complex but convenient to use, e.g.:
struct bpf_iarray_iter {
struct bpf_map *map;
u32 idx;
};
struct bpf_iset_iter bpf_iset_make_iter(struct bpf_map *map, u32 lo, u32 hi);
bool bpf_iset_iter_next(struct bpf_iarray_iter *it, u32 *offset); // still a horrible name
This would hide the manipulation with unique indices from verifier.c.
?
>
> struct bpf_insn_ptr {
> void *jitted_ip;
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 84b5e6b25c52..80d9afcca488 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -229,6 +229,10 @@ struct bpf_reg_state {
> enum bpf_reg_liveness live;
> /* if (!precise && SCALAR_VALUE) min/max/tnum don't affect safety */
> bool precise;
> +
> + /* Used to track boundaries of a PTR_TO_INSN */
> + u32 min_index;
> + u32 max_index;
Use {umin,umax}_value instead?
> };
>
> enum bpf_stack_slot_type {
> diff --git a/kernel/bpf/bpf_insn_set.c b/kernel/bpf/bpf_insn_set.c
> index c20e99327118..316cecad60a9 100644
> --- a/kernel/bpf/bpf_insn_set.c
> +++ b/kernel/bpf/bpf_insn_set.c
> @@ -9,6 +9,8 @@ struct bpf_insn_set {
> struct bpf_map map;
> struct mutex state_mutex;
> int state;
> + u32 **unique_offsets;
Why is this a pointer to pointer?
bpf_insn_set_iter_xlated_offset() is only used during check_cfg() and
main verification. At that point no instruction movement occurred yet,
so no need to track `&insn_set->ptrs[i].user_value.xlated_off`?
> + u32 unique_offsets_cnt;
> long *ips;
> DECLARE_FLEX_ARRAY(struct bpf_insn_ptr, ptrs);
> };
[...]
> @@ -15296,6 +15330,22 @@ static int adjust_reg_min_max_vals(struct bpf_verifier_env *env,
> return 0;
> }
>
> + if (dst_reg->type == PTR_TO_MAP_VALUE && map_is_insn_set(dst_reg->map_ptr)) {
> + if (opcode != BPF_ADD) {
> + verbose(env, "Operation %s on ptr to instruction set map is prohibited\n",
> + bpf_alu_string[opcode >> 4]);
> + return -EACCES;
> + }
> + src_reg = ®s[insn->src_reg];
> + if (src_reg->type != SCALAR_VALUE) {
> + verbose(env, "Adding non-scalar R%d to an instruction ptr is prohibited\n",
> + insn->src_reg);
> + return -EACCES;
> + }
> + dst_reg->min_index = src_reg->umin_value / sizeof(long);
> + dst_reg->max_index = src_reg->umax_value / sizeof(long);
> + }
> +
What if there are several BPF_ADD on the same PTR_TO_MAP_VALUE in a row?
Shouldn't the {min,max}_index be accumulated in that case?
Nit: this should be handled inside adjust_ptr_min_max_vals().
> if (dst_reg->type != SCALAR_VALUE)
> ptr_reg = dst_reg;
>
[...]
> @@ -17552,6 +17607,62 @@ static int mark_fastcall_patterns(struct bpf_verifier_env *env)
[...]
> +/* "conditional jump with N edges" */
> +static int visit_goto_x_insn(int t, struct bpf_verifier_env *env, int fd)
> +{
> + struct bpf_map *map;
> + int ret;
> +
> + ret = add_used_map(env, fd, &map);
> + if (ret < 0)
> + return ret;
> +
> + if (map->map_type != BPF_MAP_TYPE_INSN_SET)
> + return -EINVAL;
Nit: print something in the log?
> +
> + return push_goto_x_edge(t, env, map);
> +}
> +
[...]
> @@ -18786,11 +18904,22 @@ static bool func_states_equal(struct bpf_verifier_env *env, struct bpf_func_stat
> struct bpf_func_state *cur, u32 insn_idx, enum exact_level exact)
> {
> u16 live_regs = env->insn_aux_data[insn_idx].live_regs_before;
> + struct bpf_insn *insn;
> u16 i;
>
> if (old->callback_depth > cur->callback_depth)
> return false;
>
> + insn = &env->prog->insnsi[insn_idx];
> + if (insn_is_gotox(insn)) {
> + struct bpf_reg_state *old_dst = &old->regs[insn->dst_reg];
> + struct bpf_reg_state *cur_dst = &cur->regs[insn->dst_reg];
> +
> + if (old_dst->min_index != cur_dst->min_index ||
> + old_dst->max_index != cur_dst->max_index)
> + return false;
> + }
> +
Concur with Alexei, this should be handled by regsafe().
Also, having cur_dst as a subset of old_dst should be fine.
> for (i = 0; i < MAX_BPF_REG; i++)
> if (((1 << i) & live_regs) &&
> !regsafe(env, &old->regs[i], &cur->regs[i],
> @@ -19654,6 +19783,55 @@ static int process_bpf_exit_full(struct bpf_verifier_env *env,
> return PROCESS_BPF_EXIT;
> }
>
> +static int check_indirect_jump(struct bpf_verifier_env *env, struct bpf_insn *insn)
> +{
> + struct bpf_verifier_state *other_branch;
> + struct bpf_reg_state *dst_reg;
> + struct bpf_map *map;
> + int xoff;
> + int err;
> + u32 i;
> +
> + /* this map should already have been added */
> + err = add_used_map(env, insn->imm, &map);
> + if (err < 0)
> + return err;
> +
> + dst_reg = reg_state(env, insn->dst_reg);
> + if (dst_reg->type != PTR_TO_INSN) {
> + verbose(env, "BPF_JA|BPF_X R%d has type %d, expected PTR_TO_INSN\n",
> + insn->dst_reg, dst_reg->type);
> + return -EINVAL;
> + }
> +
> + if (dst_reg->map_ptr != map) {
> + verbose(env, "BPF_JA|BPF_X R%d was loaded from map id=%u, expected id=%u\n",
> + insn->dst_reg, dst_reg->map_ptr->id, map->id);
> + return -EINVAL;
> + }
> +
> + if (dst_reg->max_index >= map->max_entries)
> + return -EINVAL;
> +
> + for (i = dst_reg->min_index + 1; i <= dst_reg->max_index; i++) {
Why +1 is needed in `i = dst_reg->min_index + 1`?
> + xoff = bpf_insn_set_iter_xlated_offset(map, i);
> + if (xoff == -ENOENT)
> + break;
> + if (xoff < 0)
> + return xoff;
> +
> + other_branch = push_stack(env, xoff, env->insn_idx, false);
> + if (!other_branch)
> + return -EFAULT;
Nit: `return -ENOMEM`.
> + }
> +
> + env->insn_idx = bpf_insn_set_iter_xlated_offset(map, dst_reg->min_index);
> + if (env->insn_idx < 0)
> + return env->insn_idx;
> +
> + return 0;
> +}
> +
> static int do_check_insn(struct bpf_verifier_env *env, bool *do_print_state)
> {
> int err;
[...]
next prev parent reply other threads:[~2025-06-18 11:03 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-15 8:59 [RFC bpf-next 0/9] BPF indirect jumps Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 1/9] bpf: save the start of functions in bpf_prog_aux Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 2/9] bpf, x86: add new map type: instructions set Anton Protopopov
2025-06-18 0:57 ` Eduard Zingerman
2025-06-18 2:16 ` Alexei Starovoitov
2025-06-19 18:57 ` Anton Protopopov
2025-06-19 18:55 ` Anton Protopopov
2025-06-19 18:55 ` Eduard Zingerman
2025-06-15 8:59 ` [RFC bpf-next 3/9] selftests/bpf: add selftests for new insn_set map Anton Protopopov
2025-06-18 11:04 ` Eduard Zingerman
2025-06-18 15:16 ` Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 4/9] bpf, x86: allow indirect jumps to r8...r15 Anton Protopopov
2025-06-17 19:41 ` Alexei Starovoitov
2025-06-18 14:28 ` Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 5/9] bpf, x86: add support for indirect jumps Anton Protopopov
2025-06-18 3:06 ` Alexei Starovoitov
2025-06-19 19:57 ` Anton Protopopov
2025-06-19 19:58 ` Anton Protopopov
2025-06-18 11:03 ` Eduard Zingerman [this message]
2025-06-19 20:13 ` Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 6/9] bpf: workaround llvm behaviour with " Anton Protopopov
2025-06-18 11:04 ` Eduard Zingerman
2025-06-18 13:59 ` Alexei Starovoitov
2025-06-15 8:59 ` [RFC bpf-next 7/9] bpf: disasm: add support for BPF_JMP|BPF_JA|BPF_X Anton Protopopov
2025-06-15 8:59 ` [RFC bpf-next 8/9] libbpf: support llvm-generated indirect jumps Anton Protopopov
2025-06-18 3:22 ` Alexei Starovoitov
2025-06-18 15:08 ` Anton Protopopov
2025-07-07 23:45 ` Eduard Zingerman
2025-07-07 23:49 ` Alexei Starovoitov
2025-07-08 0:01 ` Eduard Zingerman
2025-07-08 0:12 ` Alexei Starovoitov
2025-07-08 0:18 ` Eduard Zingerman
2025-07-08 0:49 ` Alexei Starovoitov
2025-07-08 0:51 ` Eduard Zingerman
2025-07-08 20:59 ` Eduard Zingerman
2025-07-08 21:25 ` Alexei Starovoitov
2025-07-08 21:29 ` Eduard Zingerman
2025-07-09 5:33 ` Anton Protopopov
2025-07-09 5:58 ` Eduard Zingerman
2025-07-09 8:38 ` Eduard Zingerman
2025-07-10 5:11 ` Eduard Zingerman
2025-07-10 6:10 ` Anton Protopopov
2025-07-10 6:13 ` Eduard Zingerman
2025-06-18 19:49 ` Eduard Zingerman
2025-06-27 2:28 ` Eduard Zingerman
2025-06-27 10:18 ` Anton Protopopov
2025-07-03 18:21 ` Eduard Zingerman
2025-07-03 19:03 ` Anton Protopopov
2025-07-07 19:07 ` Eduard Zingerman
2025-07-07 19:34 ` Anton Protopopov
2025-07-07 21:44 ` Yonghong Song
2025-07-08 5:58 ` Yonghong Song
2025-07-08 8:30 ` Eduard Zingerman
2025-07-08 10:42 ` Eduard Zingerman
2025-06-15 8:59 ` [RFC bpf-next 9/9] selftests/bpf: add selftests for " Anton Protopopov
2025-06-18 3:24 ` Alexei Starovoitov
2025-06-18 14:49 ` Anton Protopopov
2025-06-18 16:01 ` Alexei Starovoitov
2025-06-18 16:36 ` Anton Protopopov
2025-06-18 16:43 ` Alexei Starovoitov
2025-06-18 20:25 ` Anton Protopopov
2025-06-18 21:59 ` Alexei Starovoitov
2025-06-19 5:05 ` Anton Protopopov
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=8727a800569d88f8f932333859590f702c5332ea.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=a.s.protopopov@gmail.com \
--cc=andrii@kernel.org \
--cc=aspsk@isovalent.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=qmo@kernel.org \
--cc=yonghong.song@linux.dev \
/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).