Access to a BPF map from a module

Access to a BPF map from a module

[Anton Ivanov]

Hi List,

I have the following problem.

I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.

How do I go about to obtain the map inside the module?

bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?

If the access limitation is intentional, may I ask what is the actual rationale behind this decision?

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Re: Access to a BPF map from a module

[Alexei Starovoitov]

On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
<anton.ivanov@kot-begemot.co.uk> wrote:
>
> Hi List,
>
> I have the following problem.
>
> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>
> How do I go about to obtain the map inside the module?
>
> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>
> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?

BPF objects (like maps) and BPF infra are not extensible or accessible
from modules.
That is intentional to make sure that BPF development stays on the public
mailing list and within the kernel.
If you could describe your use case we hopefully will be able to come
up with upstreamable
alternative to your proprietary module.

Re: Access to a BPF map from a module

[Anton Ivanov]

On 07/07/2021 01:53, Alexei Starovoitov wrote:
> On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
> <anton.ivanov@kot-begemot.co.uk> wrote:
>> Hi List,
>>
>> I have the following problem.
>>
>> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>>
>> How do I go about to obtain the map inside the module?
>>
>> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>>
>> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?
> BPF objects (like maps) and BPF infra are not extensible or accessible
> from modules.

Programs are.

You can grab a program using bpf_prog_get_type_path and use it. It is an exported symbol.

The only thing missing is an equivalent of bpf_prog_get_type_path for maps, let's say bpf_map_get_path

In fact, I already have a patch for that too. I wanted to understand the rationale behind the restriction before submitting it.

> That is intentional to make sure that BPF development stays on the public
> mailing list and within the kernel.
> If you could describe your use case we hopefully will be able to come
> up with upstreamable

Build a switchdev switch to be used in conjunction with the normal kernel bridge/routing infra which uses BPF "firmware"

Rationale:

1. So people can play with switchdev and smartnics in general without having esoteric hardware

2. So people can play with these both on the kernel side and on the "guts/internals" side.

> alternative to your proprietary module.
I intend to upstream it. In fact the WIP is already on github.
>
-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Re: Access to a BPF map from a module

[Daniel Borkmann]

On 7/7/21 9:09 AM, Anton Ivanov wrote:
> On 07/07/2021 01:53, Alexei Starovoitov wrote:
>> On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
>> <anton.ivanov@kot-begemot.co.uk> wrote:
>>> Hi List,
>>>
>>> I have the following problem.
>>>
>>> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>>>
>>> How do I go about to obtain the map inside the module?
>>>
>>> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>>>
>>> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?
>> BPF objects (like maps) and BPF infra are not extensible or accessible
>> from modules.
> 
> Programs are.
> 
> You can grab a program using bpf_prog_get_type_path and use it. It is an exported symbol.

Right, sadly for the netfilter xt_bpf hack as the only user. :/ The typical way to
retrieve would be to get the program via bpf_prog_get_type() from modules.

> The only thing missing is an equivalent of bpf_prog_get_type_path for maps, let's say bpf_map_get_path
> 
> In fact, I already have a patch for that too. I wanted to understand the rationale behind the restriction before submitting it.

There is a bpf_map_get(), out of curiosity, why do you need a path variant specifically?

>> That is intentional to make sure that BPF development stays on the public
>> mailing list and within the kernel.
>> If you could describe your use case we hopefully will be able to come
>> up with upstreamable
> 
> Build a switchdev switch to be used in conjunction with the normal kernel bridge/routing infra which uses BPF "firmware"
> 
> Rationale:
> 
> 1. So people can play with switchdev and smartnics in general without having esoteric hardware
> 
> 2. So people can play with these both on the kernel side and on the "guts/internals" side.

Wouldn't it be enough to load the BPF "firmware" for that switchdev in kernel via regular
prog fd, meaning similar to what we do with tc BPF case today? From a higher level it
sounds like the same use case as tc BPF just that its 'internal' to the switchdev.

>> alternative to your proprietary module.
> I intend to upstream it. In fact the WIP is already on github.

Thanks,
Daniel

Re: Access to a BPF map from a module

[Anton Ivanov]

On 07/07/2021 16:21, Daniel Borkmann wrote:
> On 7/7/21 9:09 AM, Anton Ivanov wrote:
>> On 07/07/2021 01:53, Alexei Starovoitov wrote:
>>> On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
>>> <anton.ivanov@kot-begemot.co.uk> wrote:
>>>> Hi List,
>>>>
>>>> I have the following problem.
>>>>
>>>> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>>>>
>>>> How do I go about to obtain the map inside the module?
>>>>
>>>> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>>>>
>>>> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?
>>> BPF objects (like maps) and BPF infra are not extensible or accessible
>>> from modules.
>>
>> Programs are.
>>
>> You can grab a program using bpf_prog_get_type_path and use it. It is an exported symbol.
>
> Right, sadly for the netfilter xt_bpf hack as the only user. :/ The typical way to
> retrieve would be to get the program via bpf_prog_get_type() from modules.
>
>> The only thing missing is an equivalent of bpf_prog_get_type_path for maps, let's say bpf_map_get_path
>>
>> In fact, I already have a patch for that too. I wanted to understand the rationale behind the restriction before submitting it.
>
> There is a bpf_map_get(), out of curiosity, why do you need a path variant specifically?

IIRC, I tried to use that, but ran into another not exported symbol.

In any case, I want to load the switchdev "code" as well as any supporting infra via bpftool and pin it.

The actual module is given paths to the code and maps via sysfs. This allows changing the bpf code on the fly as well as using different versions of the bpf code on a per switch interface basis.


>
>>> That is intentional to make sure that BPF development stays on the public
>>> mailing list and within the kernel.
>>> If you could describe your use case we hopefully will be able to come
>>> up with upstreamable
>>
>> Build a switchdev switch to be used in conjunction with the normal kernel bridge/routing infra which uses BPF "firmware"
>>
>> Rationale:
>>
>> 1. So people can play with switchdev and smartnics in general without having esoteric hardware
>>
>> 2. So people can play with these both on the kernel side and on the "guts/internals" side.
>
> Wouldn't it be enough to load the BPF "firmware" for that switchdev in kernel via regular
> prog fd, meaning similar to what we do with tc BPF case today? From a higher level it
> sounds like the same use case as tc BPF just that its 'internal' to the switchdev.

It is somewhat similar.

The difference is that in order to implement a working "switch" for the switchdev, you end up with multiple instances of the same program having to use common data structures as an IPC. That means loading maps, pinning them and using the pinned maps for the different instances.

>
>>> alternative to your proprietary module.
>> I intend to upstream it. In fact the WIP is already on github.
>
> Thanks,
> Daniel
>
-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Re: Access to a BPF map from a module

[Anton Ivanov]

On 07/07/2021 16:31, Anton Ivanov wrote:
>
> On 07/07/2021 16:21, Daniel Borkmann wrote:
>> On 7/7/21 9:09 AM, Anton Ivanov wrote:
>>> On 07/07/2021 01:53, Alexei Starovoitov wrote:
>>>> On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
>>>> <anton.ivanov@kot-begemot.co.uk> wrote:
>>>>> Hi List,
>>>>>
>>>>> I have the following problem.
>>>>>
>>>>> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>>>>>
>>>>> How do I go about to obtain the map inside the module?
>>>>>
>>>>> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>>>>>
>>>>> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?
>>>> BPF objects (like maps) and BPF infra are not extensible or accessible
>>>> from modules.
>>>
>>> Programs are.
>>>
>>> You can grab a program using bpf_prog_get_type_path and use it. It is an exported symbol.
>>
>> Right, sadly for the netfilter xt_bpf hack as the only user. :/ The typical way to
>> retrieve would be to get the program via bpf_prog_get_type() from modules.
>>
>>> The only thing missing is an equivalent of bpf_prog_get_type_path for maps, let's say bpf_map_get_path
>>>
>>> In fact, I already have a patch for that too. I wanted to understand the rationale behind the restriction before submitting it.
>>
>> There is a bpf_map_get(), out of curiosity, why do you need a path variant specifically?
>
> IIRC, I tried to use that, but ran into another not exported symbol.
>
> In any case, I want to load the switchdev "code" as well as any supporting infra via bpftool and pin it.
>
> The actual module is given paths to the code and maps via sysfs. This allows changing the bpf code on the fly as well as using different versions of the bpf code on a per switch interface basis.

Sorry, pressed send by mistake.

Forgot to add - the biggest hurdle in implementing a switchdev is that switchdev has to handle its notifications generated by bridge and the routing stack.

As there is no BPF support for handling notification chains and adding that is non-trivial, I need to handle them in a module in C and write them out to a map.

That is the actual use case - the module handles the notification and writes to the map. That also has to be a module. It does not belong in the kernel proper.

A.

>
>
>>
>>>> That is intentional to make sure that BPF development stays on the public
>>>> mailing list and within the kernel.
>>>> If you could describe your use case we hopefully will be able to come
>>>> up with upstreamable
>>>
>>> Build a switchdev switch to be used in conjunction with the normal kernel bridge/routing infra which uses BPF "firmware"
>>>
>>> Rationale:
>>>
>>> 1. So people can play with switchdev and smartnics in general without having esoteric hardware
>>>
>>> 2. So people can play with these both on the kernel side and on the "guts/internals" side.
>>
>> Wouldn't it be enough to load the BPF "firmware" for that switchdev in kernel via regular
>> prog fd, meaning similar to what we do with tc BPF case today? From a higher level it
>> sounds like the same use case as tc BPF just that its 'internal' to the switchdev.
>
> It is somewhat similar.
>
> The difference is that in order to implement a working "switch" for the switchdev, you end up with multiple instances of the same program having to use common data structures as an IPC. That means loading maps, pinning them and using the pinned maps for the different instances.
>
>>
>>>> alternative to your proprietary module.
>>> I intend to upstream it. In fact the WIP is already on github.
>>
>> Thanks,
>> Daniel
>>
-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/