netdev - Re: [PATCH v3 bpf-next 0/4] Add support for cgroup 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]

Date:   Tue, 31 Mar 2020 17:22:31 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     David Ahern <dsahern@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrey Ignatov <rdna@...com>, Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link

On Tue, Mar 31, 2020 at 2:52 PM Edward Cree <ecree@...arflare.com> wrote:
>
> On 31/03/2020 04:54, Andrii Nakryiko wrote:
> > No need to kill random processes, you can kill only those that hold
> > bpf_link FD. You can find them using drgn tool with script like [0].
> For the record, I find the argument "we don't need a query feature,
>  because you can just use a kernel debugger" *utterly* *horrifying*.
> Now, it seems to be moot, because Alexei has given other, better
>  reasons why query doesn't need to land yet; but can we please not
>  ever treat debugging interfaces as a substitute for proper APIs?

Can you please point out where I was objecting to observability API
(which is LINK_QUERY thing we've discussed and I didn't oppose, and
I'm going to add next)?

What I'm doubtful of is this "human override" functionality. I think a
tool that shows who's using (processes and mounted files in BPF FS)
given bpf_link is way more useful, because it allows you to both
"unblock" BPF hook (by killing "bad" processes and removing mounted
bpf_link files) and know which processes (read applications) are
misbehaving.

I'll address drgn vs not concern in reply to David Ahern, who's also
*utterly horrified*, apparently, so I'll try to calm him as well. ;)

>
> </scream>
> -ed