[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87a7315kkx.fsf@toke.dk>
Date: Fri, 24 Apr 2020 10:55:42 +0200
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.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
Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
> On Fri, Apr 24, 2020 at 01:49:03AM +0200, Toke Høiland-Jørgensen wrote:
>> Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
>>
>> > 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.
>>
>> OK, sure, can do. I do agree it's better to keep the check. I'll send a
>> proper patch tomorrow, then.
>>
>> As far as a adding a selftest for this, I think the most natural thing
>> would be to add it on top of David's tests for xdp_egress, since that's
>> what hit this - would you be OK with that? And if so, should I send the
>> main patch straight away and hold off on the selftest, or should I split
>> them, or hold off on the whole thing?
>
> I think the issue is not related to xdp egress.
> Hence I'd like to push the fix along with selftest into bpf tree.
> The selftest can be:
> void noinline do_bind((struct bpf_sock_addr *ctx)
> {
> struct sockaddr_in sa = {};
>
> bpf_bind(ctx, (struct sockaddr *)&sa, sizeof(sa));
> return 0;
> }
> SEC("cgroup/connect4")
> int connect_v4_prog(struct bpf_sock_addr *ctx)
> {
> return do_bind(ctx);
> }
>
> and freplace would replace do_bind() with do_new_bind()
> that also calls bpf_bind().
> I think without the fix freplace will fail to load, because
> availability of bpf_bind() depends on correct
> prog->expected_attach_type.
Right, I'll give this a shot, thanks :)
> I haven't looked at the crash you mentioned in the other email related
> to xdp egress set. That could be different issue. I hope it's the same
> thing :)
Yeah, it is.
-Toke
Powered by blists - more mailing lists