On Fri, Apr 24, 2020 at 05:33:11PM -0400, Kenny Ho wrote: > Hi Roman, > > To be more specific, I have been looking at the bpf-cgroup > implementation of device cgroup and I cannot wrap my head around how > the bpf-cgroup implementation would be able to enforce "[a] child > cgroup can never receive a device access which is denied by its > parent." I am either missing some understanding around device cgroup > or bpf cgroup or both. Any pointer you can give me would be much > appreciated. So as I wrote in the previous e-mail, if a program is attached to a parent cgroup, it's effectively attached to all children cgroups. So if something is prohibited on the parent level, it's also prohibited on the child level. If there is an additional program attached to the child cgroup, both programs will be executed one by one, and only if both will grant the access, it will be allowed. The only exception is if the override mode is used and the program on the child level is executed instead of the parent's program. Overall, I'd suggest you to look at kselftests and examples provided with the kernel: you can find examples of how different attach flags are used and how it works all together. Thanks! > > Regards, > Kenny > > On Fri, Apr 24, 2020 at 1:28 PM Kenny Ho <y2kenny@xxxxxxxxx> wrote: > > > > Hi Roman, > > > > Um... I am not sure yet because I don't think I understand how > > bpf-cgroup actually works. May be you can help? For example, how > > does delegation work with bpf-cgroup? What is the relationship > > between program(s) attachted to the parent cgroup and the children > > cgroups? From what I understand, the attached eBPF prog will simply > > replace what was attached by the parent (so there is no relationship?) > > Sequentially running attached program either from leaf to root or > > root to leaf is not a thing right? > > > > Regards, > > Kenny > > > > On Fri, Apr 24, 2020 at 1:08 PM Roman Gushchin <guro@xxxxxx> wrote: > > > > > > On Fri, Apr 24, 2020 at 12:43:38PM -0400, Kenny Ho wrote: > > > > Hi Roman, > > > > > > > > I am thinking of using the cgroup local storage as a way to implement > > > > per cgroup configurations that other kernel subsystem (gpu driver, for > > > > example) can have access to. Is that ok or is that crazy? > > > > > > If BPF is not involved at all, I'd say don't use it. Because beside providing > > > a generic BPF map interface (accessible from userspace and BPF), it's > > > just a page of memory "connected" to a cgroup. > > > > > > If BPF is involved, let's discuss it in more details. > > > > > > Thanks! > > > > > > > > > > > Regards, > > > > Kenny > > > > > > > > On Fri, Apr 24, 2020 at 12:26 PM Roman Gushchin <guro@xxxxxx> wrote: > > > > > > > > > > On Fri, Apr 24, 2020 at 12:17:55PM -0400, Kenny Ho wrote: > > > > > > Hi, > > > > > > > > > > > > From the documentation, eBPF maps allow sharing of data between eBPF > > > > > > kernel programs, kernel and user space applications. Does that > > > > > > applies to BPF_MAP_TYPE_CGROUP_STORAGE? If so, what is the correct > > > > > > way to access the cgroup storage from the linux kernel? I have been > > > > > > reading the __cgroup_bpf_attach function and how the storage are > > > > > > allocated and linked but I am not sure if I am on the right path. > > > > > > > > > > Hello, Kenny! > > > > > > > > > > Can you, please, elaborate a bit more on the problem, you're trying to solve? > > > > > What's the goal of accessing the cgroup storage from the kernel? > > > > > > > > > > Certainly you can get a pointer to an attached buffer if you have > > > > > a cgroup pointer. But what's next? > > > > > > > > > > Thanks!
