2019-06-06 20:18:22

by Roman Gushchin

Subject: Re: [PATCH bpf-next] bpf: allow CGROUP_SKB programs to use bpf_get_current_cgroup_id() helper

On Thu, Jun 06, 2019 at 11:59:11AM -0700, Roman Gushchin wrote:
> Currently bpf_get_current_cgroup_id() is not supported for
> CGROUP_SKB programs. An attempt to load such a program generates an
> error like this:
> libbpf:
> 0: (b7) r6 = 0
> ...
> 8: (63) *(u32 *)(r10 -28) = r6
> 9: (85) call bpf_get_current_cgroup_id#80
> unknown func bpf_get_current_cgroup_id#80
>
> There are no particular reasons for denying it,
> and we have some use cases where it might be useful.

Ah, sorry, it's not so simple, as we probably need to take
the cgroup pointer from the socket, not from current.

So the implementation of the helper should be different
for this type of programs.

So I wonder if it's better to introduce a new helper
bpf_get_sock_cgroup_id()?

What do you think?

Thanks!

2019-06-06 20:20:17

by Daniel Borkmann

Subject: Re: [PATCH bpf-next] bpf: allow CGROUP_SKB programs to use bpf_get_current_cgroup_id() helper

On 06/06/2019 09:08 PM, Roman Gushchin wrote:
> On Thu, Jun 06, 2019 at 11:59:11AM -0700, Roman Gushchin wrote:
>> Currently bpf_get_current_cgroup_id() is not supported for
>> CGROUP_SKB programs. An attempt to load such a program generates an
>> error like this:
>> libbpf:
>> 0: (b7) r6 = 0
>> ...
>> 8: (63) *(u32 *)(r10 -28) = r6
>> 9: (85) call bpf_get_current_cgroup_id#80
>> unknown func bpf_get_current_cgroup_id#80
>>
>> There are no particular reasons for denying it,
>> and we have some use cases where it might be useful.
>
> Ah, sorry, it's not so simple, as we probably need to take
> the cgroup pointer from the socket, not from current.
>
> So the implementation of the helper should be different
> for this type of programs.
>
> So I wonder if it's better to introduce a new helper
> bpf_get_sock_cgroup_id()?
>
> What do you think?

We do have bpf_skb_cgroup_id(), did you give that a try?

Thanks,
Daniel