netdev - Re: [PATCH bpf-next 04/16] net: Add BPF_XDP_EGRESS as a bpf_attach

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: <20200423224451.rkvfnv5cbnjpepgo@ast-mbp>
Date:   Thu, 23 Apr 2020 15:44:51 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     David Ahern <dsahern@...il.com>, David Ahern <dsahern@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Prashant Bhole <prashantbhole.linux@...il.com>,
        Jason Wang <jasowang@...hat.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Toshiaki Makita <toshiaki.makita1@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 04/16] net: Add BPF_XDP_EGRESS as a
 bpf_attach_type

On Thu, Apr 23, 2020 at 07:05:42PM +0200, Toke Høiland-Jørgensen wrote:
> >> >
> >> > Looks like there is indeed a bug in prog_type_ext handling code that
> >> > is doing
> >> > env->ops = bpf_verifier_ops[tgt_prog->type];
> >> > I'm not sure whether the verifier can simply add:
> >> > prog->expected_attach_type = tgt_prog->expected_attach_type;
> >> > and be done with it.
> >> > Likely yes, since expected_attach_type must be zero at that point
> >> > that is enforced by bpf_prog_load_check_attach().
> >> > So I suspect it's a single line fix.
> >>
> >> Not quite: the check in bpf_tracing_prog_attach() that enforces
> >> prog->expected_attach_type==0 also needs to go. So 5 lines :)
> >
> > prog_ext's expected_attach_type needs to stay zero.
> > It needs to be inherited from tgt prog. Hence one line:
> > prog->expected_attach_type = tgt_prog->expected_attach_type;
> 
> Not sure I follow you here? I ended up with the patch below - without
> the first hunk I can't attach freplace funcs to an xdp egress prog
> (since the expected_attach_type will have been propagated from
> verification time), and so that check will fail. Or am I missing
> something?
> 
> -Toke
> 
> 
> 
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index d85f37239540..40c3103c7233 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2381,10 +2381,6 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog)
>                 }
>                 break;
>         case BPF_PROG_TYPE_EXT:
> -               if (prog->expected_attach_type != 0) {
> -                       err = -EINVAL;
> -                       goto out_put_prog;
> -               }
>                 break;

ahh. that extra check.
I think it's better to keep it for extra safety.
Here all expected_attach_type have clear checks depending on prog_type.
There is no other place where it's that obvious.
The verifier does similar thing earlier, but it's not that clear.
I think the better fix would to set expected_attach_type = 0 for PROG_TYPE_EXT
at the end of do_check, since we're overriding this field temporarily
during verification.

>         case BPF_PROG_TYPE_LSM:
>                 if (prog->expected_attach_type != BPF_LSM_MAC) {
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 513d9c545176..41c31773a3c4 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -10485,6 +10485,7 @@ static int check_attach_btf_id(struct bpf_verifier_env *env)
>                                 return -EINVAL;
>                         }
>                         env->ops = bpf_verifier_ops[tgt_prog->type];
> +                       prog->expected_attach_type = tgt_prog->expected_attach_type;

In that sense it's like 'env->expected_attach_type'.