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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2ab2b854-723a-5f15-8c18-0b5730d1b535@meta.com>
Date:   Fri, 18 Nov 2022 13:52:00 -0500
From:   Chris Mason <clm@...a.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Florent Revest <revest@...omium.org>,
        bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        KP Singh <kpsingh@...nel.org>,
        Brendan Jackman <jackmanb@...gle.com>, markowsky@...gle.com,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Xu Kuohai <xukuohai@...wei.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe

On 11/18/22 1:06 PM, Steven Rostedt wrote:
> On Fri, 18 Nov 2022 12:44:00 -0500
> Chris Mason <clm@...a.com> 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?

https://lwn.net/Articles/811631/

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

Some of the original features:

https://lwn.net/Articles/811631/

It has changed and expanded since then, but hopefully you get the idea.

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

Honestly, I think a large scale architecture review of every BPF feature
and decision over the last 10 years is just the wrong bar for this patch
series.

 From my understanding, Mark and Florent have some changes planned
that'll improve ftrace, livepatching, and bpf.  Lets talk about those,
and tackle any long term improvements you'd like to make to BPF in other
patch series.

-chris