Question about BPF_MAP_TYPE_CGROUP_STORAGE

Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Kenny Ho]

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.

Regards,
Kenny

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Roman Gushchin]

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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Kenny Ho]

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?

Regards,
Kenny

On Fri, Apr 24, 2020 at 12:26 PM Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Roman Gushchin]

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-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Kenny Ho]

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-b10kYP2dOMg@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Kenny Ho]

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.

Regards,
Kenny

On Fri, Apr 24, 2020 at 1:28 PM Kenny Ho <y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Roman Gushchin]

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Kenny Ho]

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-b10kYP2dOMg@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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!

Re: Question about BPF_MAP_TYPE_CGROUP_STORAGE

[Roman Gushchin]

On Fri, Apr 24, 2020 at 01:28:09PM -0400, Kenny Ho 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?

Hi Kenny!

Basically an attached program runs for every process belonging to this
and all descendant cgroups. There are three modes of attachment:
basic, multi and override, which determine how programs are executed if
they are attached on multiple levels. There was a development around new
bpk_link based API (I'm not sure if it has been merged upstream already).

Thanks!


> 
> Regards,
> Kenny
> 
> On Fri, Apr 24, 2020 at 1:08 PM Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> 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-b10kYP2dOMg@public.gmane.org> 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!