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] [day] [month] [year] [list]

Date:   Wed, 1 Apr 2020 10:39:53 -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 Wed, Apr 1, 2020 at 7:26 AM Edward Cree <ecree@...arflare.com> wrote:
>
> On 01/04/2020 01:22, Andrii Nakryiko wrote:
> > 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)?
> I didn't say you objected to it.
> I just said that you argued that it was OK for it to not land in the
>  same release as the rest of the API, because drgn could paper over
>  that gap.  Which seems to me to signify a dangerous way of thinking,
>  and I wanted to raise the alarm about that.

Let's have a bit more context first. BTW, please don't trim chain of
replies (at least not so aggressively) next time.

>>> That is my point. You are restricting what root can do and people will
>>> not want to resort to killing random processes trying to find the one
>>> holding a reference. This is an essential missing piece and should go in
>>> at the same time as this set.
>> 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*.

I was addressing the concern of having to randomly kill processes.
Which is a "human override" thing, not really an observability one.
And my response is exactly that it's better to be able to see all
owners of bpf_link, rather than have a "nuke" option. It so happens
that drgn is a very useful tool for this and I was able to prototype
such script quickly enough to share it with others. drgn is not the
only option, you can do that by iterating procfs and using fdinfo. It
can certainly be improved for bpf_link-specific case by providing more
information (like cgroup path, etc). But in general, it's a question
of "which processes use given file", which unfortunately, I don't
think Linux has a better observability APIs for. I'm not happy about
that, but it's not really bpf_link-specific issue either.

> (If you _don't_ see what's wrong with that argument... well, that'd
>  be even _more_ alarming.  Debuggers — and fuser, for that matter —
>  are for when things go wrong _in ways the designers of the system
>  failed to anticipate_.  They should not be part of a 'normal' work-
>  flow for dealing with problems that we already _know_ are possible;
>  it's kinda-sorta like how exceptions shouldn't be used for non-
>  exceptional situations.)

I don't think it's as quite black and white as you are stating. For
instance, I *think* lsof, netstat, bcc tools, etc disagree with you.
Also need to kill application because it's attached to XDP or cgroup
doesn't seem like a "normal" workflow either. But I really would
rather leave it at that, if you don't mind.

>
> -ed