linux-kernel - Re: [RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for BPF based fanotify fastpath handler

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: <B3CE1128-B988-46FE-AC3B-C024C8C987CA@fb.com>
Date: Mon, 18 Nov 2024 20:51:21 +0000
From: Song Liu <songliubraving@...a.com>
To: Song Liu <songliubraving@...a.com>
CC: Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Song Liu
	<song@...nel.org>, bpf <bpf@...r.kernel.org>,
        Linux-Fsdevel
	<linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        LSM
 List <linux-security-module@...r.kernel.org>,
        Kernel Team
	<kernel-team@...a.com>,
        Andrii Nakryiko <andrii@...nel.org>, Eddy Z
	<eddyz87@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann
	<daniel@...earbox.net>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Alexander
 Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan
 Kara <jack@...e.cz>,
        KP Singh <kpsingh@...nel.org>,
        Matt Bobrowski
	<mattbobrowski@...gle.com>,
        Amir Goldstein <amir73il@...il.com>,
        "repnop@...gle.com" <repnop@...gle.com>,
        Jeff Layton <jlayton@...nel.org>, Josef Bacik <josef@...icpanda.com>,
        Mickaël Salaün
	<mic@...ikod.net>,
        "gnoack@...gle.com" <gnoack@...gle.com>
Subject: Re: [RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for
 BPF based fanotify fastpath handler



> On Nov 15, 2024, at 1:05 PM, Song Liu <songliubraving@...a.com> wrote:

[...]
> 
>> 
>> fsnotify_open_perm->fsnotify->send_to_group->fanotify_handle_event.
>> 
>> is a pretty long path to call bpf prog and
>> preparing a giant 'struct fanotify_fastpath_event'
>> is not going to fast either.
>> 
>> If we want to accelerate that with bpf it needs to be done
>> sooner with negligible overhead.
> 
> Agreed. This is actually something I have been thinking 
> since the beginning of this work: Shall it be fanotify-bpf 
> or fsnotify-bpf. Given we have more materials, this is a 
> good time to have broader discussions on this. 
> 
> @all, please chime in whether we should redo this as
> fsnotify-bpf. AFAICT:
> 
> Pros of fanotify-bpf: 
> - There is existing user space that we can leverage/reuse.
> 
> Pros of fsnotify-bpf: 
> - Faster fast path. 
> 
> Another major pros/cons did I miss?

Adding more thoughts on this: I think it makes more sense to
go with fanotify-bpf. This is because one of the benefits of
fsnotify/fanotify over LSM solutions is the built-in event
filtering of events. While this call chain is a bit long:

fsnotify_open_perm->fsnotify->send_to_group->fanotify_handle_event.

There are built-in filtering in fsnotify() and 
send_to_group(), so logics in the call chain are useful. 

struct fanotify_fastpath_event is indeed big. But I think
we need to pass these information to the fastpath handler
either way. 


Overall, I think current fastpath design makes sense, 
though there are things we need to fix (as Amir and Alexei
pointed out). Please let me know comments and suggestions
on this. 

Thanks,
Song