From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, "Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin KaFai Lau" <kafai@fb.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>, "Lorenz Bauer" <linux@lmb.io>,
Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v1 1/5] bpf: Add ARG_SCALAR and ARG_CONSTANT
Date: Tue, 8 Mar 2022 11:56:02 +0530 [thread overview]
Message-ID: <20220308062602.7aydtzkk5ghyo5gb@apollo.legion> (raw)
In-Reply-To: <CAEf4Bza0smGgyty87gfbUM8z5i+QOFvVqH+VHYcQxobODxCvfQ@mail.gmail.com>
On Tue, Mar 08, 2022 at 11:12:13AM IST, Andrii Nakryiko wrote:
> On Sun, Mar 6, 2022 at 3:43 PM Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> >
> > In the next patch, we will introduce a new helper 'bpf_packet_pointer'
> > that takes offset and len and returns a packet pointer. There we want to
> > statically enforce offset is in range [0, 0xffff], and that len is a
> > constant value, in range [1, 0xffff]. This also helps us avoid a
> > pointless runtime check. To make these checks possible, we need to
> > ensure we only get a scalar type. Although a lot of other argument types
> > take scalars, their intent is different. Hence add general ARG_SCALAR
> > and ARG_CONSTANT types, where the latter is also checked to be constant
> > in addition to being scalar.
> >
> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> > ---
> > include/linux/bpf.h | 2 ++
> > kernel/bpf/verifier.c | 13 +++++++++++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 88449fbbe063..7841d90b83df 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -391,6 +391,8 @@ enum bpf_arg_type {
> > ARG_PTR_TO_STACK, /* pointer to stack */
> > ARG_PTR_TO_CONST_STR, /* pointer to a null terminated read-only string */
> > ARG_PTR_TO_TIMER, /* pointer to bpf_timer */
> > + ARG_SCALAR, /* a scalar with any value(s) */
>
> What's the difference between ARG_ANYTHING and ARG_SCALAR?
>
ARG_SCALAR only accepts reg->type == SCALAR, ARG_ANYTHING accepts anything as
long as reg->type != NOT_INIT (due to SRC_OP for check_reg_arg and early return
without further checks).
> > + ARG_CONSTANT, /* a scalar with constant value */
>
> This ARG_CONSTANT serves a very similar purpose as
> ARG_CONST_ALLOC_SIZE_OR_ZERO, tbh. The only difference is that one is
> used to set meta->mem_size and this one is used (through extra func_id
> special handling) to set meta->ret_pkt_len. But meta->mem_size and
> meta->ret_pkt_len mean the same thing: how many bytes are directly
> accessible through a pointer returned from the helper. So I feel like
> there is some opportunity to unify and generalize, instead of adding
> more custom variants of constants. WDYT?
>
I see, indeed it would make sense to make both equivalent, since
CONST_ALLOC_SIZE must also be a constant. Joanne also mentioned consolidating,
but I didn't understand how that would work for ARG_CONSTANT and ARG_CONST_SIZE
ones.
I'm wondering whether we can take a step back and should go with the following
convention:
ARG_MEM_SIZE, and two type flags, ARG_ZERO | ARG_CONSTANT
Old New (in bpf_func_proto)
-------------------------------------------------------------------
ARG_CONST_SIZE ARG_MEM_SIZE
ARG_CONST_SIZE_OR_ZERO ARG_MEM_SIZE | ARG_ZERO
ARG_CONST_ALLOC_SIZE ARG_MEM_SIZE | ARG_CONST
ARG_CONST_ALLOC_SIZE_OR_ZERO ARG_MEM_SIZE | ARG_CONST | ARG_ZERO
ARG_CONSTANT (mine) ARG_MEM_SIZE | ARG_CONST
When we detect ARG_CONST, we always set meta->mem_size, which can be used to
refine returned pointer range, otherwise meta->mem_size = -1 by default (so it
will be -1 for the !tnum_is_const(reg->var_off) case).
if (arg_type & ARG_CONST)
meta->mem_size = reg->var_off.value;
if (!(arg_type & ARG_ZERO) && !meta->mem_size)
// error
The check_mem_size_reg call is only made when we see that previous reg was
ARG_PTR_TO_MEM. When preceding argument is not ARG_PTR_TO_MEM, we error if
ARG_CONST is not set for ARG_MEM_SIZE (so that either the mem size is for
previous parameter, or otherwise a constant size for the returned pointer).
We can also only allow certain pointer return types for that case.
If that is too much automagic, we can also discern using ARG_MEM_SIZE vs
ARG_RET_MEM_SIZE, but I think the above is fine.
ARG_CONST ofcourse only applies to args taking scalar type.
>
>
> > __BPF_ARG_TYPE_MAX,
> >
> > /* Extended arg_types. */
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index ec3a7b6c9515..0373d5bd240f 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5163,6 +5163,12 @@ static bool arg_type_is_int_ptr(enum bpf_arg_type type)
> > type == ARG_PTR_TO_LONG;
> > }
> >
> > +static bool arg_type_is_scalar(enum bpf_arg_type type)
> > +{
> > + return type == ARG_SCALAR ||
> > + type == ARG_CONSTANT;
> > +}
> > +
> > static int int_ptr_type_to_size(enum bpf_arg_type type)
> > {
> > if (type == ARG_PTR_TO_INT)
> > @@ -5302,6 +5308,8 @@ static const struct bpf_reg_types *compatible_reg_types[__BPF_ARG_TYPE_MAX] = {
> > [ARG_PTR_TO_STACK] = &stack_ptr_types,
> > [ARG_PTR_TO_CONST_STR] = &const_str_ptr_types,
> > [ARG_PTR_TO_TIMER] = &timer_types,
> > + [ARG_SCALAR] = &scalar_types,
> > + [ARG_CONSTANT] = &scalar_types,
> > };
> >
> > static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
> > @@ -5635,6 +5643,11 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> > verbose(env, "string is not zero-terminated\n");
> > return -EINVAL;
> > }
> > + } else if (arg_type_is_scalar(arg_type)) {
> > + if (arg_type == ARG_CONSTANT && !tnum_is_const(reg->var_off)) {
> > + verbose(env, "R%d is not a known constant\n", regno);
> > + return -EACCES;
> > + }
> > }
> >
> > return err;
> > --
> > 2.35.1
> >
--
Kartikeya
next prev parent reply other threads:[~2022-03-08 6:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 23:43 [PATCH bpf-next v1 0/5] Introduce bpf_packet_pointer helper Kumar Kartikeya Dwivedi
2022-03-06 23:43 ` [PATCH bpf-next v1 1/5] bpf: Add ARG_SCALAR and ARG_CONSTANT Kumar Kartikeya Dwivedi
2022-03-07 19:28 ` Joanne Koong
2022-03-07 21:22 ` Kumar Kartikeya Dwivedi
2022-03-08 5:42 ` Andrii Nakryiko
2022-03-08 6:26 ` Kumar Kartikeya Dwivedi [this message]
2022-03-10 23:05 ` Andrii Nakryiko
2022-03-10 23:09 ` Andrii Nakryiko
2022-03-11 7:31 ` Kumar Kartikeya Dwivedi
2022-03-06 23:43 ` [PATCH bpf-next v1 2/5] bpf: Introduce pkt_uid concept for PTR_TO_PACKET Kumar Kartikeya Dwivedi
2022-03-06 23:43 ` [PATCH bpf-next v1 3/5] bpf: Introduce bpf_packet_pointer helper to do DPA Kumar Kartikeya Dwivedi
2022-03-06 23:43 ` [PATCH bpf-next v1 4/5] selftests/bpf: Add verifier tests for pkt pointer with pkt_uid Kumar Kartikeya Dwivedi
2022-03-06 23:43 ` [PATCH bpf-next v1 5/5] selftests/bpf: Update xdp_adjust_frags to use bpf_packet_pointer Kumar Kartikeya Dwivedi
2022-03-08 5:48 ` [PATCH bpf-next v1 0/5] Introduce bpf_packet_pointer helper Andrii Nakryiko
2022-03-08 7:08 ` Kumar Kartikeya Dwivedi
2022-03-08 13:40 ` Toke Høiland-Jørgensen
2022-03-10 23:12 ` Andrii Nakryiko
2022-03-10 23:30 ` Toke Høiland-Jørgensen
2022-03-10 23:35 ` Alexei Starovoitov
2022-03-11 7:25 ` Kumar Kartikeya Dwivedi
2022-03-11 7:32 ` Kumar Kartikeya Dwivedi
2022-03-11 17:27 ` Alexei Starovoitov
2022-03-11 7:19 ` Kumar Kartikeya Dwivedi
2022-03-11 10:34 ` Toke Høiland-Jørgensen
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=20220308062602.7aydtzkk5ghyo5gb@apollo.legion \
--to=memxor@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=linux@lmb.io \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.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