Thread (30 messages) 30 messages, 6 authors, 2021-05-11

Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL

From: Alexei Starovoitov <hidden>
Date: 2020-11-03 05:32:51
Also in: amd-gfx, bpf, cgroups, linux-fsdevel

On Mon, Nov 02, 2020 at 02:23:02PM -0500, Kenny Ho wrote:
Adding a few more emails from get_maintainer.pl and bumping this
thread since there hasn't been any comments so far.  Is this too
crazy?  Am I missing something fundamental?
sorry for delay. Missed it earlier. Feel free to ping the mailing list
sooner next time.
On Wed, Oct 7, 2020 at 11:24 AM Kenny Ho [off-list ref] wrote:
quoted
This is a skeleton implementation to invite comments and generate
discussion around the idea of introducing a bpf-cgroup program type to
control ioctl access.  This is modelled after
BPF_PROG_TYPE_CGROUP_DEVICE.  The premise is to allow system admins to
write bpf programs to block some ioctl access, potentially in conjunction
with data collected by other bpf programs stored in some bpf maps and
with bpf_spin_lock.

For example, a bpf program has been accumulating resource usaging
statistic and a second bpf program of BPF_PROG_TYPE_CGROUP_IOCTL would
block access to previously mentioned resource via ioctl when the stats
stored in a bpf map reaches certain threshold.

Like BPF_PROG_TYPE_CGROUP_DEVICE, the default is permissive (i.e.,
ioctls are not blocked if no bpf program is present for the cgroup.) to
maintain current interface behaviour when this functionality is unused.

Performance impact to ioctl calls is minimal as bpf's in-kernel verifier
ensure attached bpf programs cannot crash and always terminate quickly.

TODOs:
- correct usage of the verifier
- toolings
- samples
- device driver may provide helper functions that take
bpf_cgroup_ioctl_ctx and return something more useful for specific
device

Signed-off-by: Kenny Ho <redacted>
...
quoted
@@ -45,6 +46,10 @@ long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
        if (!filp->f_op->unlocked_ioctl)
                goto out;

+       error = BPF_CGROUP_RUN_PROG_IOCTL(filp, cmd, arg);
+       if (error)
+               goto out;
+
That's a bit problematic, since we have bpf_lsm now.
Could you use security_file_ioctl hook and do the same filtering there?
It's not cgroup based though. Is it a concern?
If cgroup scoping is really necessary then it's probably better
to add it to bpf_lsm. Then all hooks will become cgroup aware.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help