Re: [net-next 0/2] BPF, kprobes: Add current_in_cgroup helper

On Sat, Aug 06, 2016 at 09:56:06PM -0700, Sargun Dhillon wrote:

On Sat, Aug 06, 2016 at 09:32:05PM -0700, Alexei Starovoitov wrote:

quoted

On Sat, Aug 06, 2016 at 09:06:53PM -0700, Sargun Dhillon wrote:

quoted

This patchset includes a helper and an example to determine whether the kprobe 
is currently executing in the context of a specific cgroup based on a cgroup
bpf map / array. 

description is too short to understand how this new helper is going to be used.
depending on kprobe current is not always valid.

Anything not in in_interrupt() should have a current, right?

quoted

what are you trying to achieve?

This is primarily to help troubleshoot containers (Docker, and now systemd). A 
lot of the time we want to determine what's going on in a given container 
(opening files, connecting to systems, etc...). There's not really a great way 
to restrict to containers except by manually walking datastructures to check for 
the right cgroup. This seems like a better alternative.

so it's about restricting or determining?
In other words if it's analytics/tracing that's one thing, but
enforcement/restriction is quite different.
For analytics one can walk task_css_set(current)->dfl_cgrp and remember
that pointer in a map or something for stats collections and similar.
If it's restricting apps in containers then kprobe approach
is not usable. I don't think you'd want to built an enforcement system
on an unstable api then can vary kernel-to-kernel.

quoted

This looks like an alternative to lsm patches submitted earlier?

No. But I would like to use this helper in the LSM patches I'm working on. For 
now, with those patches, and this helper, I can create a map sized 1, and add 
the cgroup I care about to it. Given I can add as many bpf programs to an LSM
hook I want, I can use this mechanism to "attach BPF programs to cgroups" -- 
I put that in quotes because you're not really attaching it to a cgroup,
but just burning some instructions on checking it. 

how many cgroups will you need to check? The current bpf_skb_in_cgroup()
suffers similar scaling issues.
I think the proper restriction/enforcement could be done via attaching bpf
program to a cgroup. These patches are being worked on Daniel Mack cc-ed.
Then bpf program will be able to enforce networking behavior of applications
in cgroups.
For global container analytics I think we need something that converts
current to cgroup_id or cgroup_handle. I don't think descendant check
can scale for such use case.