netdev - Re: [RFC PATCH bpf-next 0/8] bpf

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: <CAEf4Bzb4HJNzpyF=yRsS1CjiZK1qZ57QmiFUH2-hh46u+OFs7A@mail.gmail.com>
Date:   Sun, 5 Apr 2020 11:31:15 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     David Ahern <dsahern@...il.com>
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: [RFC PATCH bpf-next 0/8] bpf_link observability APIs

On Sun, Apr 5, 2020 at 9:26 AM David Ahern <dsahern@...il.com> wrote:
>
> On 4/3/20 6:09 PM, Andrii Nakryiko wrote:
> > This patch series adds various observability APIs to bpf_link:
> >   - each bpf_link now gets ID, similar to bpf_map and bpf_prog, by which
> >     user-space can iterate over all existing bpf_links and create limited FD
> >     from ID;
> >   - allows to get extra object information with bpf_link general and
> >     type-specific information;
> >   - makes LINK_UPDATE operation allowed only for writable bpf_links and allows
> >     to pin bpf_link as read-only file;
> >   - implements `bpf link show` command which lists all active bpf_links in the
> >     system;
> >   - implements `bpf link pin` allowing to pin bpf_link by ID or from other
> >     pinned path.
> >
> > This RFC series is missing selftests and only limited amount of manual testing
> > was performed. But kernel implementation is hopefully in a good shape and
> > won't change much (unless some big issues are identified with the current
> > approach). It would be great to get feedback on approach and implementation,
> > before I invest more time in writing tests.
> >
>
> The word 'ownership' was used over and over in describing the benefits
> of bpf_link meaning a process owns a program at a specific attach point.
> How does this set allow me to discover the pid of the process
> controlling a specific bpf_link?

In general, it's many processes, not a single process. Here's how:

1. Each bpf_link has a unique ID.
2. You can find desired bpf_link info (including ID) either by already
having FD and querying it with GET_OBJ_INFO_BY_FD, or by doing
GET_NEXT_ID iteration and then GET_FD_BY_ID + GET_OBJ_INFO_BY_FD.
3. Iterate all open files (either by using tools like drgn or by
iterating over procfs), check their fdinfo to see if it's bpf_link's
with given ID. This gives you which application has FD open against
given bpf_link.

Similarly one can iterate over all pinned files in bpffs and see if it
pins bpf_link (I believe bpftool can do that already and show which
objects are pinned, so it should be a minimal change to actually print
out all the pinned file paths).

Does that answer your question?