netdev - Re: [PATCH bpf-next v1 06/19] bpf: support bpf tracing/iter programs for BPF_LINK

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]

Date:   Tue, 28 Apr 2020 23:41:44 -0700
From:   Martin KaFai Lau <kafai@...com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next v1 06/19] bpf: support bpf tracing/iter programs
 for BPF_LINK_UPDATE

On Tue, Apr 28, 2020 at 11:32:15PM -0700, Andrii Nakryiko wrote:
> On Tue, Apr 28, 2020 at 10:59 PM Martin KaFai Lau <kafai@...com> wrote:
> >
> > On Tue, Apr 28, 2020 at 10:04:54PM -0700, Yonghong Song wrote:
> > >
> > >
> > > On 4/28/20 6:32 PM, Martin KaFai Lau wrote:
> > > > On Mon, Apr 27, 2020 at 01:12:41PM -0700, Yonghong Song wrote:
> > > > > Added BPF_LINK_UPDATE support for tracing/iter programs.
> > > > > This way, a file based bpf iterator, which holds a reference
> > > > > to the link, can have its bpf program updated without
> > > > > creating new files.
> > > > >
> >
> > [ ... ]
> >
> > > > > --- a/kernel/bpf/bpf_iter.c
> > > > > +++ b/kernel/bpf/bpf_iter.c
> >
> > [ ... ]
> >
> > > > > @@ -121,3 +125,28 @@ int bpf_iter_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
> > > > >                   kfree(link);
> > > > >           return err;
> > > > >   }
> > > > > +
> > > > > +int bpf_iter_link_replace(struct bpf_link *link, struct bpf_prog *old_prog,
> > > > > +                   struct bpf_prog *new_prog)
> > > > > +{
> > > > > + int ret = 0;
> > > > > +
> > > > > + mutex_lock(&bpf_iter_mutex);
> > > > > + if (old_prog && link->prog != old_prog) {
> > hmm....
> >
> > If I read this function correctly,
> > old_prog could be NULL here and it is only needed during BPF_F_REPLACE
> > to ensure it is replacing a particular old_prog, no?
> 
> Yes, do you see any problem with the above logic?
Not at all.  I just want to point out that when old_prog is NULL,
the link_update() would not even call bpf_prog_put(old_prog).

> 
> >
> >
> > > > > +         ret = -EPERM;
> > > > > +         goto out_unlock;
> > > > > + }
> > > > > +
> > > > > + if (link->prog->type != new_prog->type ||
> > > > > +     link->prog->expected_attach_type != new_prog->expected_attach_type ||
> > > > > +     strcmp(link->prog->aux->attach_func_name, new_prog->aux->attach_func_name)) {
> > > > Can attach_btf_id be compared instead of strcmp()?
> > >
> > > Yes, we can do it.
> > >
> > > >
> > > > > +         ret = -EINVAL;
> > > > > +         goto out_unlock;
> > > > > + }
> > > > > +
> > > > > + link->prog = new_prog;
> > > > Does the old link->prog need a bpf_prog_put()?
> > >
> > > The old_prog is replaced in caller link_update (syscall.c):
> >
> > > static int link_update(union bpf_attr *attr)
> > > {
> > >         struct bpf_prog *old_prog = NULL, *new_prog;
> > >         struct bpf_link *link;
> > >         u32 flags;
> > >         int ret;
> > > ...
> > >         if (link->ops == &bpf_iter_link_lops) {
> > >                 ret = bpf_iter_link_replace(link, old_prog, new_prog);
> > >                 goto out_put_progs;
> > >         }
> > >         ret = -EINVAL;
> > >
> > > out_put_progs:
> > >         if (old_prog)
> > >                 bpf_prog_put(old_prog);
> > The old_prog in link_update() took a separate refcnt from bpf_prog_get().
> > I don't see how it is related to the existing refcnt held in the link->prog.
> >
> > or I am missing something in BPF_F_REPLACE?
> 
> Martin is right, bpf_iter_link_replace() needs to drop its own refcnt
> on old_prog, in addition to what generic link_update logic does here,
> because bpf_link_iter bumped old_prog's refcnt when it was created or
> updated last time.