Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 20 Jun 2022 09:13:44 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> This statement is the issue. There's not a clear line of what
> constitutes what eBPF is being used for, and worse, what is guaranteed
> to work across kernel versions.
> 
> My fear is that we will start having an expectation that pretty much
> any eBPF program will continue to work, and there's going to be a lot
> of disgruntled users when it doesn't.
> 
> Having configuration uses is one thing, enabling full device
> functionality is another. And anything that touches core interfaces
> need to be scrutinized.
> 
> If we look at where BPF came from (iptables et.al.) and having it do
> nothing more that that but for other parts of the system, it may be a
> good start. But even that could introduce dependencies of internal
> kernel implementations that could break over time. Basically, we can
> try to not break BPF programs but we really need the decree that it's
> not user API, and does not follow the "don't break user space" agenda,
> as anything that uses eBPF, is *not* user space. It's just another kind
> of kernel module.
> 
> And if an eBPF program does break, if the source of that program is not
> available, then the answer to fixing it should be "tough luck". This
> should not be a way for proprietary code to have their kernel API.

I'm currently at the Open Source Summit, and Dirk basically asked my
question almost verbatim to Linus (during the "Dirk and Linus show").

And Linus stated that there is no defined "API". It's just "do not
break user space tools", and this includes eBPF. That is, if something
that is useful in user space that breaks with an upgrade, what breaks
it either gets reverted, or a "fix" is done to make it work again.

Linus specified that when it gets to eBPF programs that do debugging or
tracing, or other really low level interactions with the kernel, then
if it breaks a user space tool that is doing this low level work, then
that's just part of the work flow (fix user space to match, it's
already dependent on the kernel implementations). He specified if you
break "real user space tools, that normal (non kernel developers) users
use" then you need to fix it, regardless if it is using eBPF or not.

This still does not address the problem. First, where's the line where a
tool becomes something for normal users?

Next, eBPF can now attach to pretty much *any* function, and modify how
that function operates (changing parameters, etc) Basically, eBPF can
do live kernel patching like changes.

If a new feature is implemented with eBPF and that eBPF feature depends
on some internal kernel implementation, where the maintainer of that
code is unaware of this new eBPF implemented feature, if they change
their code and break this, then the burden is on the maintainer to fix
that breakage, not those that implemented the eBPF feature.

This is the worry I have. Maintainers now have no control over what is
exposed to users that can become 'user API", aka break normal user
tooling, without having a clue that something now depends on the
implementation of their code.

We really need to take a step back before we let eBPF become fully
controlling of anything in the kernel. Because that's going to add a
huge burden on maintainers that do not even use eBPF.

Exposing information for consumption only is one thing, and what I
would like to have more of, but once you allow non-passive interactions
with the tracing infrastructure, it changes things where I can see a
lot of maintainers will have more push back against the former (reading
only tracing, as there's no way to keep it from making changes).

-- Steve