Message-ID: <87pm64z8th.fsf@toke.dk>
Date: Fri, 09 Jun 2023 22:20:42 +0200
From: Toke Høiland-Jørgensen <toke@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Timo Beckers <timo@...line.eu>, Daniel Borkmann <daniel@...earbox.net>,
 Stanislav Fomichev <sdf@...gle.com>, ast@...nel.org, andrii@...nel.org,
 martin.lau@...ux.dev, razor@...ckwall.org, john.fastabend@...il.com,
 kuba@...nel.org, dxu@...uu.xyz, joe@...ium.io, davem@...emloft.net,
 bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 1/7] bpf: Add generic attach/detach/query
 API for multi-progs

>> >>> See above on the issues w/o the first/last. How would you work around them
>> >>> in practice so they cannot happen?
>> >> By having an ordering configuration that is deterministic. Enforced by
>> >> the system-wide management daemon by whichever mechanism suits it. We
>> >> could implement a minimal reference policy agent that just reads a
>> >> config file in /etc somewhere, and *that* could implement FIRST/LAST
>> >> semantics.
>> > I think this particular perspective is what's deadlocking this discussion.
>> > To me, it looks like distros and hyperscalers are in the same boat with
>> > regards to the possibility of coordination between tools. Distros are only
>> > responsible for the tools they package themselves, and hyperscalers
>> > run a tight ship with mostly in-house tooling already. When it comes to
>> > projects out in the wild, that all goes out the window.
>>
>> Not really: from the distro PoV we absolutely care about arbitrary
>> combinations of programs with different authors. Which is why I'm
>> arguing against putting anything into the kernel where the first program
>> to come along can just grab a hook and lock everyone out.
>
> What if some combinations of programs just cannot co-exist?
>
>
> Me, Daniel, Timo are arguing that there are real situations where you
> have to be first or need to die.

Right, and what I'm saying is that this decision should not be up to
individual applications to decide for the whole system. I'm OK with an
application *requesting* that, but it should be possible for a
system-level policy to override that request. I don't actually care so
much about the mechanism for doing so; I just don't want to expose a
flag in UAPI that comes with such a "lock everything" promise, because
that explicitly prevents such system overrides.

> And the counter argument we are getting is "but someone can
> accidentally or in bad faith overuse F_FIRST". The former is causing
> real problems and silent failures. The latter is about fixing bugs
> and/or fighting bad actors. We don't propose any real solution for the
> real first problem, because we are afraid of hypothetical bad actors.
> The former has a technical solution (F_FIRST/F_LAST), the latter is a
> matter of bug fixing and pushing back on bad actors. This is where
> distros can actually help by making sure that bad actors that don't
> really need F_FIRST/F_LAST are not using them.

It's not about "bad actors" in the malicious sense, it's about decisions
being made in one context not being valid in another. Take Daniel's
example of a DDOS application. It's probably a quite legitimate choice
for the developers of such an application to say "it only makes sense to
run a DDOS application first, so of course we'll set the FIRST flag".
But it is just as legitimate for a user/admin to say "I actually want to
run this DDOS application after this other application I wrote for that
specific purpose". If we enforce the FIRST flag semantics at the kernel
level we're making a decision that the first case is legitimate and the
second isn't, and that's just not true.

The whole datadog/cilium issue shows exactly that this kind of conflict
*is* how things play out in practice.

-Toke

Powered by blists - more mailing lists