| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAADnVQ+sXH-9ffONAdggbix427iiX3mzn1f1_SwLJH=+pBfcJQ@mail.gmail.com>
Date: Wed, 23 Sep 2020 08:24:58 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Lorenz Bauer <lmb@...udflare.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH bpf-next v4 11/11] bpf: use a table to drive helper arg
type checks
On Wed, Sep 23, 2020 at 2:45 AM Lorenz Bauer <lmb@...udflare.com> wrote:
>
> On Tue, 22 Sep 2020 at 21:07, Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Tue, Sep 22, 2020 at 09:20:27AM +0100, Lorenz Bauer wrote:
> > > On Mon, 21 Sep 2020 at 23:23, Alexei Starovoitov
> > > <alexei.starovoitov@...il.com> wrote:
> > > >
> > > > On Mon, Sep 21, 2020 at 01:12:27PM +0100, Lorenz Bauer wrote:
> > > > > +struct bpf_reg_types {
> > > > > + const enum bpf_reg_type types[10];
> > > > > +};
> > > >
> > > > any idea on how to make it more robust?
> > >
> > > I kind of copied this from the bpf_iter context. I prototyped using an
> > > enum bpf_reg_type * and then terminating the array with NOT_INIT.
> > > Writing this out is more involved, and might need some macro magic to
> > > make it palatable. The current approach is a lot simpler, and I
> > > figured that the compiler will error out if we ever exceed the 10
> > > items.
> >
> > The compiler will be silent if number of types is exactly 10,
> > but at run-time the loop will access out of bounds.
>
> Which loop do you refer to?
>
> The one in check_reg_type shouldn't go out of bounds due to ARRAY_SIZE:
>
> for (i = 0; i < ARRAY_SIZE(compatible->types); i++) {
ahh. right. it will always be 10 here. got it.
> expected = compatible->types[i];
> if (expected == NOT_INIT)
> break;
>
> >
> > > >
> > > > > +
> > > > > +static const struct bpf_reg_types *compatible_reg_types[] = {
> > > > > + [ARG_PTR_TO_MAP_KEY] = &map_key_value_types,
> > > > > + [ARG_PTR_TO_MAP_VALUE] = &map_key_value_types,
> > > > > + [ARG_PTR_TO_UNINIT_MAP_VALUE] = &map_key_value_types,
> > > > > + [ARG_PTR_TO_MAP_VALUE_OR_NULL] = &map_key_value_types,
> > > > > + [ARG_CONST_SIZE] = &scalar_types,
> > > > > + [ARG_CONST_SIZE_OR_ZERO] = &scalar_types,
> > > > > + [ARG_CONST_ALLOC_SIZE_OR_ZERO] = &scalar_types,
> > > > > + [ARG_CONST_MAP_PTR] = &const_map_ptr_types,
> > > > > + [ARG_PTR_TO_CTX] = &context_types,
> > > > > + [ARG_PTR_TO_CTX_OR_NULL] = &context_types,
> > > > > + [ARG_PTR_TO_SOCK_COMMON] = &sock_types,
> > > > > + [ARG_PTR_TO_SOCKET] = &fullsock_types,
> > > > > + [ARG_PTR_TO_SOCKET_OR_NULL] = &fullsock_types,
> > > > > + [ARG_PTR_TO_BTF_ID] = &btf_ptr_types,
> > > > > + [ARG_PTR_TO_SPIN_LOCK] = &spin_lock_types,
> > > > > + [ARG_PTR_TO_MEM] = &mem_types,
> > > > > + [ARG_PTR_TO_MEM_OR_NULL] = &mem_types,
> > > > > + [ARG_PTR_TO_UNINIT_MEM] = &mem_types,
> > > > > + [ARG_PTR_TO_ALLOC_MEM] = &alloc_mem_types,
> > > > > + [ARG_PTR_TO_ALLOC_MEM_OR_NULL] = &alloc_mem_types,
> > > > > + [ARG_PTR_TO_INT] = &int_ptr_types,
> > > > > + [ARG_PTR_TO_LONG] = &int_ptr_types,
> > > > > + [__BPF_ARG_TYPE_MAX] = NULL,
> > > >
> > > > I don't understand what this extra value is for.
> > > > I tried:
> > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > > > index fc5c901c7542..87b0d5dcc1ff 100644
> > > > --- a/include/linux/bpf.h
> > > > +++ b/include/linux/bpf.h
> > > > @@ -292,7 +292,6 @@ enum bpf_arg_type {
> > > > ARG_PTR_TO_ALLOC_MEM, /* pointer to dynamically allocated memory */
> > > > ARG_PTR_TO_ALLOC_MEM_OR_NULL, /* pointer to dynamically allocated memory or NULL */
> > > > ARG_CONST_ALLOC_SIZE_OR_ZERO, /* number of allocated bytes requested */
> > > > - __BPF_ARG_TYPE_MAX,
> > > > };
> > > >
> > > > /* type of values returned from helper functions */
> > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > index 15ab889b0a3f..83faa67858b6 100644
> > > > --- a/kernel/bpf/verifier.c
> > > > +++ b/kernel/bpf/verifier.c
> > > > @@ -4025,7 +4025,6 @@ static const struct bpf_reg_types *compatible_reg_types[] = {
> > > > [ARG_PTR_TO_ALLOC_MEM_OR_NULL] = &alloc_mem_types,
> > > > [ARG_PTR_TO_INT] = &int_ptr_types,
> > > > [ARG_PTR_TO_LONG] = &int_ptr_types,
> > > > - [__BPF_ARG_TYPE_MAX] = NULL,
> > > > };
> > > >
> > > > and everything is fine as I think it should be.
> > > >
> > > > > + compatible = compatible_reg_types[arg_type];
> > > > > + if (!compatible) {
> > > > > + verbose(env, "verifier internal error: unsupported arg type %d\n", arg_type);
> > > > > return -EFAULT;
> > > > > }
> > > >
> > > > This check will trigger the same way when somebody adds new ARG_* and doesn't add to the table.
> > >
> > > I think in that case that value of compatible will be undefined, since
> > > it points past the end of compatible_reg_types. Hence the
> > > __BPF_ARG_TYPE_MAX to ensure that the array has a NULL slot for new
> > > arg types.
> >
> > I still don't see a point.
> > If anyone adds one more ARG_ to the end (or anywhere else)
> > the compatible_reg_types array will be zero inited in that place by the compiler.
> > Just like it does already for ARG_ANYTHING and ARG_DONTCARE.
>
> I looked up designated initializers when I wrote this, since I wasn't
> super familiar with them:
> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html#Designated-Inits
>
> Note that the length of the array is the highest value specified plus one.
>
> So ARG_ANYTHING and ARG_DONTCARE are OK since there is a higher enum
> value present in the initializer. If someone adds a new item to enum
> bpf_arg_type I assume they would add it to the end. In that case the
> highest value of the initializer doesn't change, and then indexing
> into compatible_reg_types with the new enum value would be out of
> bounds. Adding __BPF_ARG_TYPE_MAX fixes that.
I see. Could you do this instead then:
-static const struct bpf_reg_types *compatible_reg_types[] = {
+static const struct bpf_reg_types *compatible_reg_types[__BPF_ARG_TYPE_MAX] = {
[ARG_PTR_TO_MAP_KEY] = &map_key_value_types,
[ARG_PTR_TO_MAP_VALUE] = &map_key_value_types,
[ARG_PTR_TO_UNINIT_MAP_VALUE] = &map_key_value_types,
@@ -4025,7 +4025,6 @@ static const struct bpf_reg_types
*compatible_reg_types[] = {
[ARG_PTR_TO_ALLOC_MEM_OR_NULL] = &alloc_mem_types,
[ARG_PTR_TO_INT] = &int_ptr_types,
[ARG_PTR_TO_LONG] = &int_ptr_types,
- [__BPF_ARG_TYPE_MAX] = NULL,
};
That way is more obvious.
That =NULL initializer just for the last element and not for
ARG_ANYTHING/DONTCARE
bothered me enough to start this whole discussion.
Powered by blists - more mailing lists