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: > > On Sat, Aug 06, 2016 at 09:06:53PM -0700, Sargun Dhillon wrote: > > > 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? > > > 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. > > 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.