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

[Steven Rostedt]

On Fri, 18 Nov 2022 12:44:00 -0500
Chris Mason <clm@xxxxxxxx> wrote:

> > 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.

What struct ops interfaces?

>  There are also explicit allow lists to
> limit functions where you can do return value overrides etc, so I think

Where are these lists.

> it's fair to say these concerns are already baked in.  I'm sure they can

How do I know that a function return was modified by BPF? If I'm debugging
something, is it obvious to the developer that is debugging an issue
(perhaps unaware of what BPF programs are loaded on the users machine),
that the return of a function was tweaked by BPF and that could be the
source of the bug?

> be improved over the long term, but I don't think that's related to this
> set of functionality on ARM.

I disagree. These issues may have been added to x86, but perhaps we should
take a deeper look at them again before extending them to other
architectures.

-- Steve