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

[Song Liu]

> On Nov 14, 2024, at 4:41 PM, Alexei Starovoitov <alexei.starovoitov at gmail.com> wrote:
> 
> On Thu, Nov 14, 2024 at 3:02 PM Song Liu <songliubraving at meta.com> wrote:
>> 
>> 
>> 
>>> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov at gmail.com> wrote:
>>> 
>>> On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song at kernel.org> wrote:
>>>> 
>>>> +
>>>> +       if (bpf_is_subdir(dentry, v->dentry))
>>>> +               ret = FAN_FP_RET_SEND_TO_USERSPACE;
>>>> +       else
>>>> +               ret = FAN_FP_RET_SKIP_EVENT;
>>> 
>>> It seems to me that all these patches and feature additions
>>> to fanotify, new kfuncs, etc are done just to do the above
>>> filtering by subdir ?
>>> 
>>> If so, just hard code this logic as an extra flag to fanotify ?
>>> So it can filter all events by subdir.
>>> bpf programmability makes sense when it needs to express
>>> user space policy. Here it's just a filter by subdir.
>>> bpf hammer doesn't look like the right tool for this use case.
>> 
>> Current version is indeed tailored towards the subtree
>> monitoring use case. This is mostly because feedback on v1
>> mostly focused on this use case. V1 itself actually had some
>> other use cases.
> 
> like?

samples/fanotify in v1 shows pattern that matches file prefix 
(no BPF). selftests/bpf in v1 shows a pattern where we 
propagate a flag in inode local storage from parent directory
to newly created children directory. 

> 
>> In practice, fanotify fastpath can benefit from bpf
>> programmability. For example, with bpf programmability, we
>> can combine fanotify and BPF LSM in some security use cases.
>> If some security rules only applies to a few files, a
>> directory, or a subtree, we can use fanotify to only monitor
>> these files. LSM hooks, such as security_file_open(), are
>> always global. The overhead is higher if we are only
>> interested in a few files.
>> 
>> Does this make sense?
> 
> Not yet.
> This fanotify bpf filtering only reduces the number of events
> sent to user space.
> How is it supposed to interact with bpf-lsm?

Ah, I didn't explain this part. fanotify+bpf fastpath can 
do more reducing number of events sent to user space. It can
also be used in tracing use cases. For example, we can 
implement a filetop tool that only monitors a specific 
directory, a specific device, or a specific mount point.
It can also reject some file access (fanotify permission 
mode). I should have showed these features in a sample 
and/or selftest.

> Say, security policy applies to /usr/bin/*
> so lsm suppose to act on all files and subdirs in there.
> How fanotify helps ?

LSM hooks are always global. It is up to the BPF program
to filter out irrelevant events. This filtering is 
sometimes expensive (match d_patch) and inaccurate 
(maintain a map of target inodes, etc.). OTOH, fanotify 
has built-in filtering before the BPF program triggers. 
When multiple BPF programs are monitoring open() for 
different subdirectories, fanotify based solution will 
not trigger all these BPF programs for all the open() 
in the system.

Does this answer the questions?

Thanks,
Song