netdev - Re: [PATCH bpf-next v2 1/7] bpf: Add generic attach/detach/query API for multi-progs

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: <CAEf4Bza9Dwi0_75CGPjdoirg97aoygLkChu-6q2DbOnRwZKGZQ@mail.gmail.com>
Date: Thu, 8 Jun 2023 17:08:34 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Stanislav Fomichev <sdf@...gle.com>, Daniel Borkmann <daniel@...earbox.net>, 
	Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Nikolay Aleksandrov <razor@...ckwall.org>, 
	John Fastabend <john.fastabend@...il.com>, Jakub Kicinski <kuba@...nel.org>, Daniel Xu <dxu@...uu.xyz>, 
	Joe Stringer <joe@...ium.io>, Toke Høiland-Jørgensen <toke@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, bpf <bpf@...r.kernel.org>, 
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 1/7] bpf: Add generic attach/detach/query API
 for multi-progs

On Thu, Jun 8, 2023 at 4:55 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Jun 8, 2023 at 4:06 PM Stanislav Fomichev <sdf@...gle.com> wrote:
> >
> > I'm not really concerned about our production environment. It's pretty
> > controlled and restricted and I'm pretty certain we can avoid doing
> > something stupid. Probably the same for your env.
> >
> > I'm mostly fantasizing about upstream world where different users don't
> > know about each other and start doing stupid things like F_FIRST where
> > they don't really have to be first. It's that "used judiciously" part
> > that I'm a bit skeptical about :-D
> >
> > Because even with this new ordering scheme, there still should be
> > some entity to do relative ordering (systemd-style, maybe CNI?).
> > And if it does the ordering, I don't really see why we need
> > F_FIRST/F_LAST.
>
> +1.
> I have the same concerns as expressed during lsfmmbpf.
> This first/last is a foot gun.
> It puts the whole API back into a single user situation.
> Without "first api" the users are forced to talk to each other
> and come up with an arbitration mechanism. A daemon to control
> the order or something like that.
> With "first api" there is no incentive to do so.

If Cilium and some other company X both produce, say, anti-DDOS
solution which cannot co-exist with any other anti-DDOS program and
either of them needs to guarantee that their program runs first, then
FIRST is what would be used by both to prevent accidental breakage of
each other (which is basically what happened with Cilium and some
other networking solution, don't remember the name). It's better for
one of them to loudly fail to attach than silently break other
solution with end users struggling to understand what's going on.

You and Stanislav keep insisting that any combination of any BPF
programs should co-exist, and I don't understand why we can or should
presume that. I think we are conflating generic API (and kernel *not*
making any assumptions about such API usage) with encouraging
collaborative BPF attachment policies. They are orthogonal and are not
in conflict with each other.

But we lived without FIRST/LAST guarantees till now, that's fine, I'll
stop fighting this.