[bpf-next,2/3] bpf: allow passing struct bpf_iter_<type> as kfunc arguments

Commit Message

Andrii Nakryiko Aug. 8, 2024, 11:22 p.m. UTC

There are potentially useful cases where a specific iterator type might
need to be passed into some kfunc. So, in addition to existing
bpf_iter_<type>_{new,next,destroy}() kfuncs, allow to pass iterator
pointer to any kfunc.

We employ "__iter" naming suffix for arguments that are meant to accept
iterators. We also enforce that they accept PTR -> STRUCT btf_iter_<type>
type chain and point to a valid initialized on-the-stack iterator state.

Signed-off-by: Andrii Nakryiko <[e-mail]>
---
 kernel/bpf/verifier.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

Comments

Eduard Zingerman Aug. 9, 2024, 7:14 p.m. UTC | #1

On Thu, 2024-08-08 at 16:22 -0700, Andrii Nakryiko wrote:
> There are potentially useful cases where a specific iterator type might
> need to be passed into some kfunc. So, in addition to existing
> bpf_iter_<type>_{new,next,destroy}() kfuncs, allow to pass iterator
> pointer to any kfunc.
> 
> We employ "__iter" naming suffix for arguments that are meant to accept
> iterators. We also enforce that they accept PTR -> STRUCT btf_iter_<type>
> type chain and point to a valid initialized on-the-stack iterator state.
> 
> Signed-off-by: Andrii Nakryiko <[e-mail]>
> ---

In current form this allows the following usage:

    SEC("?socket")
    __success
    int testmod_seq_getter_good(const void *ctx)
    {
    	struct bpf_iter_testmod_seq it;
    	s64 sum = 0;
    
    	bpf_iter_testmod_seq_new(&it, 100, 100);
    	sum *= bpf_iter_testmod_seq_value(0, &it);
    	bpf_iter_testmod_seq_destroy(&it);
    
    	return sum;
    }

Do we want to ensure that iterator is not drained before the call to
bpf_iter_testmod_seq_value()?

Otherwise this patch lgtm.

[...]

Andrii Nakryiko Aug. 9, 2024, 7:28 p.m. UTC | #2

On Fri, Aug 9, 2024 at 12:14 PM Eduard Zingerman <[e-mail]> wrote:
>
> On Thu, 2024-08-08 at 16:22 -0700, Andrii Nakryiko wrote:
> > There are potentially useful cases where a specific iterator type might
> > need to be passed into some kfunc. So, in addition to existing
> > bpf_iter_<type>_{new,next,destroy}() kfuncs, allow to pass iterator
> > pointer to any kfunc.
> >
> > We employ "__iter" naming suffix for arguments that are meant to accept
> > iterators. We also enforce that they accept PTR -> STRUCT btf_iter_<type>
> > type chain and point to a valid initialized on-the-stack iterator state.
> >
> > Signed-off-by: Andrii Nakryiko <[e-mail]>
> > ---
>
> In current form this allows the following usage:
>
>     SEC("?socket")
>     __success
>     int testmod_seq_getter_good(const void *ctx)
>     {
>         struct bpf_iter_testmod_seq it;
>         s64 sum = 0;
>
>         bpf_iter_testmod_seq_new(&it, 100, 100);
>         sum *= bpf_iter_testmod_seq_value(0, &it);
>         bpf_iter_testmod_seq_destroy(&it);
>
>         return sum;
>     }
>
> Do we want to ensure that iterator is not drained before the call to
> bpf_iter_testmod_seq_value()?
>

I'm not sure I follow your question. Drained or not it's still a valid
iterator state. I don't want to put any restrictions, the user is free
to pass it at any point between new and destroy.


> Otherwise this patch lgtm.
>
> [...]
>

Eduard Zingerman Aug. 9, 2024, 7:40 p.m. UTC | #3

On Fri, 2024-08-09 at 12:28 -0700, Andrii Nakryiko wrote:

[...]

> I'm not sure I follow your question. Drained or not it's still a valid
> iterator state.

E.g. make sure that some such functions might be called only after a
call to next() that returned a value.

> I don't want to put any restrictions, the user is free
> to pass it at any point between new and destroy.

Ok, as you say.

[...]

Andrii Nakryiko Aug. 9, 2024, 8:36 p.m. UTC | #4

On Fri, Aug 9, 2024 at 12:40 PM Eduard Zingerman <[e-mail]> wrote:
>
> On Fri, 2024-08-09 at 12:28 -0700, Andrii Nakryiko wrote:
>
> [...]
>
> > I'm not sure I follow your question. Drained or not it's still a valid
> > iterator state.
>
> E.g. make sure that some such functions might be called only after a
> call to next() that returned a value.

if that's important for some specific kfunc, it can handle that easily
internally, I don't think we need to complicate verifier with
something like that, even if that might have been useful for some
niche use cases.

>
> > I don't want to put any restrictions, the user is free
> > to pass it at any point between new and destroy.
>
> Ok, as you say.
>
> [...]
>

Patch

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index df3be12096cf..920d7c5fe944 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -7970,12 +7970,17 @@  static bool is_iter_destroy_kfunc(struct bpf_kfunc_call_arg_meta *meta)
 	return meta->kfunc_flags & KF_ITER_DESTROY;
 }
 
-static bool is_kfunc_arg_iter(struct bpf_kfunc_call_arg_meta *meta, int arg)
+static bool is_kfunc_arg_iter(struct bpf_kfunc_call_arg_meta *meta, int arg_idx,
+			      const struct btf_param *arg)
 {
 	/* btf_check_iter_kfuncs() guarantees that first argument of any iter
 	 * kfunc is iter state pointer
 	 */
-	return arg == 0 && is_iter_kfunc(meta);
+	if (is_iter_kfunc(meta))
+		return arg_idx == 0;
+
+	/* iter passed as an argument to a generic kfunc */
+	return btf_param_match_suffix(meta->btf, arg, "__iter");
 }
 
 static int process_iter_arg(struct bpf_verifier_env *env, int regno, int insn_idx,
@@ -7983,14 +7988,20 @@  static int process_iter_arg(struct bpf_verifier_env *env, int regno, int insn_id
 {
 	struct bpf_reg_state *regs = cur_regs(env), *reg = &regs[regno];
 	const struct btf_type *t;
-	const struct btf_param *arg;
-	int spi, err, i, nr_slots;
-	u32 btf_id;
+	int spi, err, i, nr_slots, btf_id;
 
-	/* btf_check_iter_kfuncs() ensures we don't need to validate anything here */
-	arg = &btf_params(meta->func_proto)[0];
-	t = btf_type_skip_modifiers(meta->btf, arg->type, NULL);	/* PTR */
-	t = btf_type_skip_modifiers(meta->btf, t->type, &btf_id);	/* STRUCT */
+	/* For iter_{new,next,destroy} functions, btf_check_iter_kfuncs()
+	 * ensures struct convention, so we wouldn't need to do any BTF
+	 * validation here. But given iter state can be passed as a parameter
+	 * to any kfunc, if arg has "__iter" suffix, we need to be a bit more
+	 * conservative here.
+	 */
+	btf_id = btf_check_iter_arg(meta->btf, meta->func_proto, regno - 1);
+	if (btf_id < 0) {
+		verbose(env, "expected valid iter pointer as arg #%d\n", regno);
+		return -EINVAL;
+	}
+	t = btf_type_by_id(meta->btf, btf_id);
 	nr_slots = t->size / BPF_REG_SIZE;
 
 	if (is_iter_new_kfunc(meta)) {
@@ -8012,7 +8023,9 @@  static int process_iter_arg(struct bpf_verifier_env *env, int regno, int insn_id
 		if (err)
 			return err;
 	} else {
-		/* iter_next() or iter_destroy() expect initialized iter state*/
+		/* iter_next() or iter_destroy(), as well as any kfunc
+		 * accepting iter argument, expect initialized iter state
+		 */
 		err = is_iter_reg_valid_init(env, reg, meta->btf, btf_id, nr_slots);
 		switch (err) {
 		case 0:
@@ -11382,7 +11395,7 @@  get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
 	if (is_kfunc_arg_dynptr(meta->btf, &args[argno]))
 		return KF_ARG_PTR_TO_DYNPTR;
 
-	if (is_kfunc_arg_iter(meta, argno))
+	if (is_kfunc_arg_iter(meta, argno, &args[argno]))
 		return KF_ARG_PTR_TO_ITER;
 
 	if (is_kfunc_arg_list_head(meta->btf, &args[argno]))