Re: [RFC 0/1] BPF tracing for arm64 using fprobe

From: Steven Rostedt <rostedt@goodmis.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Chris Mason <clm@meta.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Florent Revest <revest@chromium.org>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	KP Singh <kpsingh@kernel.org>,
	Brendan Jackman <jackmanb@google.com>,
	markowsky@google.com, Masami Hiramatsu <mhiramat@kernel.org>,
	Xu Kuohai <xukuohai@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe
Date: Fri, 18 Nov 2022 11:45:19 -0500	[thread overview]
Message-ID: <20221118114519.2711d890@gandalf.local.home> (raw)
In-Reply-To: <Y3e0KtnQrudxiZbz@FVFF77S0Q05N.cambridge.arm.com>

On Fri, 18 Nov 2022 16:34:50 +0000
Mark Rutland <mark.rutland@arm.com> wrote:

> > Not alarmist, but concern as being able to modify what a kernel function can
> > do is not something I take lightly.  
> 
> FWIW, given that the aim here seems to be to expose all kernel internals to be
> overridden arbitrarily, I'm also concerned that there's a huge surface area for
> issues with maintainability, robustness/correctness, and security.
> 
> I really don't want to be stuck in a position where someone argues that all
> kernel internal functions are ABI and need to stay around as-is to be hooked by
> eBPF, and I hope that we all agree that there are no guarantees on that front.

My biggest concern is changing functionality of arbitrary functions by BPF.
I would much rather limit what functions BPF could change with some
annotation.

int __bpf_modify foo()
{
	...
}

That way if somethings not working, you can see directly in the code that
the function could be modified by a BPF program, instead of getting some
random bug report because a function returned an unexpected result that the
code of that function could never produce.

-- Steve