Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I see.  Thanks for the pointers.  I will look into it.

Regards,
Kenny

On Mon, Apr 27, 2020 at 11:25 AM Roman Gushchin <guro@xxxxxx> wrote:
>
> 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!



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux