[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241122225958.1775625-1-song@kernel.org>
Date: Fri, 22 Nov 2024 14:59:56 -0800
From: Song Liu <song@...nel.org>
To: bpf@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Cc: kernel-team@...a.com,
andrii@...nel.org,
eddyz87@...il.com,
ast@...nel.org,
daniel@...earbox.net,
martin.lau@...ux.dev,
viro@...iv.linux.org.uk,
brauner@...nel.org,
jack@...e.cz,
kpsingh@...nel.org,
mattbobrowski@...gle.com,
amir73il@...il.com,
repnop@...gle.com,
jlayton@...nel.org,
josef@...icpanda.com,
mic@...ikod.net,
gnoack@...gle.com,
Song Liu <song@...nel.org>
Subject: [PATCH v3 fanotify 0/2] Fanotify in kernel filter
This is the first part of v2.
Changes v2 => v3:
1. v3 is the fanotify part of v2.
2. Rebrand as fanotify in kernel filter (instead of fastpath handler).
3. Fix logic and add sample for permission mmode.
[v2]: https://lore.kernel.org/linux-fsdevel/20241114084345.1564165-1-song@kernel.org/
Changes v1 => v2:
1. Add sysfs entries for fastpath handler.
2. Rewrite the sample and bpf selftest to handle subtree monitoring.
This requires quite some work from BPF side to properly handle
inode, dentry, etc.
3. Add CONFIG_FANOTIFY_FASTPATH.
4. Add more documents.
>From v1 RFC:
This RFC set introduces in-kernel fastpath handler for fanotify. The
fastpath handler can be used to handle/filter some events without going
through userspace.
In LPC 2024, multiple talks covered use cases of monitoring a subtree in
the VFS (fanotify: [1], bpf/lsm: [2]). This work is inspired by these
discussions. Reliably monitoring of a subtree with low overhead is a hard
problem. We do not claim this set fully solves problem. But we think this
work can be a very useful building block of the solution to this problem.
The fastpath handler can be implemented with built-in logic, in a kernel
module, or a bpf program. The fastpath handler is attached to a fsnotify
group. With current implementation, the multiple fastpath handlers are
maintained in a global list. Only users with CAP_SYS_ADMIN can add
fastpath handlers to the list by loading a kernel module. User without
CAP_SYS_ADMIN can attach a loaded fastpath handler to fanotify instances.
During the attach operation, the fastpath handler can take an argument.
This enables non-CAP_SYSADMIN users to customize/configure the fastpath
handler, for example, with a specific allowlist/denylist.
As the patchset grows to 1000+ lines (including samples and tests), I
would like some feedback before pushing it further.
[1] https://lpc.events/event/18/contributions/1717/
[2] https://lpc.events/event/18/contributions/1940/
Song Liu (2):
fanotify: Introduce fanotify filter
samples/fanotify: Add a sample fanotify fiter
MAINTAINERS | 1 +
fs/notify/fanotify/Kconfig | 13 ++
fs/notify/fanotify/Makefile | 1 +
fs/notify/fanotify/fanotify.c | 44 +++-
fs/notify/fanotify/fanotify_filter.c | 289 +++++++++++++++++++++++++++
fs/notify/fanotify/fanotify_user.c | 7 +
include/linux/fanotify.h | 128 ++++++++++++
include/linux/fsnotify_backend.h | 6 +-
include/uapi/linux/fanotify.h | 36 ++++
samples/Kconfig | 20 +-
samples/Makefile | 2 +-
samples/fanotify/.gitignore | 1 +
samples/fanotify/Makefile | 5 +-
samples/fanotify/filter-mod.c | 105 ++++++++++
samples/fanotify/filter-user.c | 131 ++++++++++++
samples/fanotify/filter.h | 19 ++
16 files changed, 801 insertions(+), 7 deletions(-)
create mode 100644 fs/notify/fanotify/fanotify_filter.c
create mode 100644 samples/fanotify/filter-mod.c
create mode 100644 samples/fanotify/filter-user.c
create mode 100644 samples/fanotify/filter.h
--
2.43.5
Powered by blists - more mailing lists