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: <43d5d1f5-c01d-c0db-b421-386331c2b8c1@meta.com>
Date:   Fri, 18 Nov 2022 12:44:00 -0500
From:   Chris Mason <clm@...a.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Mark Rutland <mark.rutland@....com>
Cc:     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 11:45 AM, Steven Rostedt wrote:
> On Fri, 18 Nov 2022 16:34:50 +0000
> Mark Rutland <mark.rutland@....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.
> 

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