On Wed, Jul 31, 2024 at 4:09 AM Matt Bobrowski <mattbobrowski@xxxxxxxxxx> wrote: > > Add a new variant of bpf_d_path() named bpf_path_d_path() which takes > the form of a BPF kfunc and enforces KF_TRUSTED_ARGS semantics onto > its arguments. > > This new d_path() based BPF kfunc variant is intended to address the > legacy bpf_d_path() BPF helper's susceptability to memory corruption > issues [0, 1, 2] by ensuring to only operate on supplied arguments > which are deemed trusted by the BPF verifier. Typically, this means > that only pointers to a struct path which have been referenced counted > may be supplied. > > In addition to the new bpf_path_d_path() BPF kfunc, we also add a > KF_ACQUIRE based BPF kfunc bpf_get_task_exe_file() and KF_RELEASE > counterpart BPF kfunc bpf_put_file(). This is so that the new > bpf_path_d_path() BPF kfunc can be used more flexibily from within the > context of a BPF LSM program. It's rather common to ascertain the > backing executable file for the calling process by performing the > following walk current->mm->exe_file while instrumenting a given > operation from the context of the BPF LSM program. However, walking > current->mm->exe_file directly is never deemed to be OK, and doing so > from both inside and outside of BPF LSM program context should be > considered as a bug. Using bpf_get_task_exe_file() and in turn > bpf_put_file() will allow BPF LSM programs to reliably get and put > references to current->mm->exe_file. > > As of now, all the newly introduced BPF kfuncs within this patch are > limited to BPF LSM program types. These can be either sleepable or > non-sleepable variants of BPF LSM program types. > > [0] https://lore.kernel.org/bpf/CAG48ez0ppjcT=QxU-jtCUfb5xQb3mLr=5FcwddF_VKfEBPs_Dg@xxxxxxxxxxxxxx/ > [1] https://lore.kernel.org/bpf/20230606181714.532998-1-jolsa@xxxxxxxxxx/ > [2] https://lore.kernel.org/bpf/20220219113744.1852259-1-memxor@xxxxxxxxx/ > > Acked-by: Christian Brauner <brauner@xxxxxxxxxx> > Signed-off-by: Matt Bobrowski <mattbobrowski@xxxxxxxxxx> Acked-by: Song Liu <song@xxxxxxxxxx> with one nitpic below > --- > fs/Makefile | 1 + > fs/bpf_fs_kfuncs.c | 127 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 128 insertions(+) > create mode 100644 fs/bpf_fs_kfuncs.c > > diff --git a/fs/Makefile b/fs/Makefile > index 6ecc9b0a53f2..61679fd587b7 100644 > --- a/fs/Makefile > +++ b/fs/Makefile > @@ -129,3 +129,4 @@ obj-$(CONFIG_EFIVAR_FS) += efivarfs/ > obj-$(CONFIG_EROFS_FS) += erofs/ > obj-$(CONFIG_VBOXSF_FS) += vboxsf/ > obj-$(CONFIG_ZONEFS_FS) += zonefs/ > +obj-$(CONFIG_BPF_LSM) += bpf_fs_kfuncs.o > diff --git a/fs/bpf_fs_kfuncs.c b/fs/bpf_fs_kfuncs.c > new file mode 100644 > index 000000000000..2a66331d8921 > --- /dev/null > +++ b/fs/bpf_fs_kfuncs.c > @@ -0,0 +1,127 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) 2024 Google LLC. */ > + > +#include <linux/bpf.h> > +#include <linux/btf.h> > +#include <linux/btf_ids.h> > +#include <linux/dcache.h> > +#include <linux/err.h> > +#include <linux/fs.h> > +#include <linux/file.h> > +#include <linux/init.h> > +#include <linux/mm.h> > +#include <linux/path.h> > +#include <linux/sched.h> It appears we don't need to include all these headers. With my daily config, #include <linux/bpf.h> alone is sufficient. Thanks, Song
