Re: [PATCH bpf-next v4 11/11] bpf: use a table to drive helper arg type checks

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

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@gmail.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.

> >
> > > +
> > > +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.
Am I still missing something?
If not please follow up with removal of __BPF_ARG_TYPE_MAX.