netdev - Re: [PATCH bpf-next 3/6] bpf: implement bpf_link-based cgroup BPF program attachment

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: <CAEf4BzYh-DieT1yDmwfg0KrdgCjUNPn6ougvWQhn2htk75ecnQ@mail.gmail.com>
Date:   Fri, 20 Mar 2020 14:47:21 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Stanislav Fomichev <sdf@...ichev.me>
Cc:     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 3/6] bpf: implement bpf_link-based cgroup BPF
 program attachment

On Fri, Mar 20, 2020 at 2:33 PM Stanislav Fomichev <sdf@...ichev.me> wrote:
>
> On 03/20, Andrii Nakryiko wrote:
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 5d01c5c7e598..fad9f79bb8f1 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -111,6 +111,7 @@ enum bpf_cmd {
> >       BPF_MAP_LOOKUP_AND_DELETE_BATCH,
> >       BPF_MAP_UPDATE_BATCH,
> >       BPF_MAP_DELETE_BATCH,
> [..]
> > +     BPF_LINK_CREATE,
> Curious, why did you decide to add new command versus reusing existing
> BPF_PROG_ATTACH/BPF_PROG_DETACH pair? Can we have a new flag like
> BPF_F_NOT_OWNED that we can set when calling BPF_PROG_ATTACH to trigger
> all these new bpf_link properties (like cgroup not holding an extra ref)?

It was my initial approach, but I've got internal feedback that this
will be actually more confusing than useful. E.g., for bpf_link case,
BPF_PROG_DETACH is disabled, so having BPF_PROG_ATTACH is creating a
false expectation in this case. BPF_PROG attach is returning 0 on
succes and <0 on error, but BPF_LINK_CREATE is returning error or >0
FD.

Also with BPF_LINK_UPDATE, it makes more sense to have dedicated
per-link operations.