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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACAyw98XfkMy4TDFnHBCFzXxauLrZ56w+84-R_NQO1SLMgPJYA@mail.gmail.com>
Date:   Tue, 22 Sep 2020 09:20:27 +0100
From:   Lorenz Bauer <lmb@...udflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.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 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.

>
> > +
> > +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.

>
> >
> > +     err = check_reg_type(env, regno, compatible);
> > +     if (err)
> > +             return err;
> > +
> >       if (type == PTR_TO_BTF_ID) {
> >               const u32 *btf_id = fn->arg_btf_id[arg];
> >
> > @@ -4174,10 +4213,6 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> >       }
> >
> >       return err;
> > -err_type:
> > -     verbose(env, "R%d type=%s expected=%s\n", regno,
> > -             reg_type_str[type], reg_type_str[expected_type]);
> > -     return -EACCES;
>
> I'm not a fan of table driven checks. I think one explicit switch statement
> would have been easier to read, but I guess we can convert back to it later if
> table becomes too limiting. The improvement in the verifier output is important
> and justifies this approach.
>
> Applied to bpf-next. Thanks!

Thank you!

--
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com