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

From: Chris Mason
Date: Fri Nov 18 2022 - 12:45:06 EST


On 11/18/22 11:45 AM, Steven Rostedt wrote:
On Fri, 18 Nov 2022 16:34:50 +0000
Mark Rutland <mark.rutland@xxxxxxx> 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.


For ABI concerns, I don't think we're doing anything fundamentally
different from x86 here. So unless our ARM users are substantially more
exciting than the x86 crowd, it should all fall under the discussion
from maintainer's summit:

https://lwn.net/Articles/908464/

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.


The good news is that BPF generally confines the function replacement
through struct ops interfaces. There are also explicit allow lists to
limit functions where you can do return value overrides etc, so I think
it's fair to say these concerns are already baked in. I'm sure they can
be improved over the long term, but I don't think that's related to this
set of functionality on ARM.

-chris