netdev - Re: [PATCH v3 bpf-next 8/9] tools/bpftool: show info for processes holding BPF map/prog/link/btf FDs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEf4BzYYas7Lz3cxUhUigo=f-PKCfa-ZOwsD_cfmVkbSVy3qCQ@mail.gmail.com>
Date:   Mon, 22 Jun 2020 22:09:19 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...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>, Hao Luo <haoluo@...gle.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Song Liu <songliubraving@...com>,
        Quentin Monnet <quentin@...valent.com>
Subject: Re: [PATCH v3 bpf-next 8/9] tools/bpftool: show info for processes
 holding BPF map/prog/link/btf FDs

On Mon, Jun 22, 2020 at 5:24 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Fri, Jun 19, 2020 at 04:17:02PM -0700, Andrii Nakryiko wrote:
> > Add bpf_iter-based way to find all the processes that hold open FDs against
> > BPF object (map, prog, link, btf). bpftool always attempts to discover this,
> > but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
> > Process name and PID are emitted for each process (task group).
> >
> > Sample output for each of 4 BPF objects:
> >
> > $ sudo ./bpftool prog show
> > 2694: cgroup_device  tag 8c42dee26e8cd4c2  gpl
> >         loaded_at 2020-06-16T15:34:32-0700  uid 0
> >         xlated 648B  jited 409B  memlock 4096B
> >         pids systemd(1)
> > 2907: cgroup_skb  name egress  tag 9ad187367cf2b9e8  gpl
> >         loaded_at 2020-06-16T18:06:54-0700  uid 0
> >         xlated 48B  jited 59B  memlock 4096B  map_ids 2436
> >         btf_id 1202
> >         pids test_progs(2238417), test_progs(2238445)
> >
> > $ sudo ./bpftool map show
> > 2436: array  name test_cgr.bss  flags 0x400
> >         key 4B  value 8B  max_entries 1  memlock 8192B
> >         btf_id 1202
> >         pids test_progs(2238417), test_progs(2238445)
> > 2445: array  name pid_iter.rodata  flags 0x480
> >         key 4B  value 4B  max_entries 1  memlock 8192B
> >         btf_id 1214  frozen
> >         pids bpftool(2239612)
>
> Overall it's a massive improvement, so I've applied the set.
>
> But above 'map show' probably needs a comment in the output.
> bpftool is showing a map that was loaded temporarily.
> It doesn't do so for programs though.

Yeah, and that confused me enough to just spend a bunch of time trying
to understand why. It seems like all the files are closed properly and
it just so happens that program and link is cleaned up in kernel soon
enough for bpftool to never get it with BPF_PROG_GET_NEXT_ID, while
map and btf destruction is delayed and they do get returned.

> I think somehow highlighting that above map is bpftool's own map
> that was used to generate this output would be good.
> Filtering it completely out is probably not correct.

If you have an example of a message you'd like to see, let me know.
But given detecting that this is a "special bpftool's" map/btf is the
same as filtering out in terms of reliability (e.g., by PID or by
map/btf id), I actually think that filtering it out would be less
confusing (and simpler for bpftool output code).

>
> > $ sudo ./bpftool btf show
> > 1202: size 1527B  prog_ids 2908,2907  map_ids 2436
> >         pids test_progs(2238417), test_progs(2238445)
> > 1242: size 34684B
> >         pids bpftool(2258892)
>
> similar.
>
> I've also noticed that 'test_progs -t btf_map_in_map' leaks 'inner_map2'.
> Doesn't look like the test is pinning it, so I'm guessing
> a recent kernel regression? I haven't debugged it.

Yep, neither it's pinned, nor any process has an FD open against it,
so must be kernel reference leak...