Re: [PATCH bpf-next 1/2] bpf: Add dentry kfuncs for BPF LSM programs

[David Windsor <dwindsor@gmail.com>]

On Wed, Sep 24, 2025 at 8:29 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Wed, Sep 24, 2025 at 08:08:03PM -0400, David Windsor wrote:
> > On Wed, Sep 24, 2025 at 7:55 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Wed, Sep 24, 2025 at 07:24:33PM -0400, David Windsor wrote:
> > > > Add six new BPF kfuncs that enable BPF LSM programs to safely interact
> > > > with dentry objects:
> > > >
> > > > - bpf_dget(): Acquire reference on dentry
> > > > - bpf_dput(): Release reference on dentry
> > > > - bpf_dget_parent(): Get referenced parent dentry
> > > > - bpf_d_find_alias(): Find referenced alias dentry for inode
> > > > - bpf_file_dentry(): Get dentry from file
> > > > - bpf_file_vfsmount(): Get vfsmount from file
> > > >
> > > > All kfuncs are currently restricted to BPF_PROG_TYPE_LSM programs.
> > >
> > > You have an interesting definition of safety.
> > >
> > > We are *NOT* letting random out-of-tree code play around with the
> > > lifetime rules for core objects.
> > >
> >
> > File references are already exposed to bpf (bpf_get_task_exe_file,
> > bpf_put_file) with the same KF_ACQUIRE|KF_RELEASE semantics. These
> > follow the same pattern and are also LSM-only.
>
> You can safely clone and retain file references.  You can't do that
> to dentries unless you are guaranteed an active reference to superblock
> to stay around for as long as you are retaining those.  Note that
> LSM hooks might be called with ->s_umount held by caller, so the locking
> environment for superblocks depends upon the hook in question.

Yeah good point about ->s_umount, why don't we just create a new "safe
dentry hooks" BTF ID set and restrict this to those and filter in
bpf_fs_kfuncs_filter, where there's existing filtering going on
anyway?