Access to rodata when using libbpf directly

Access to rodata when using libbpf directly

[Grant Seltzer Richman]

As I understand it, accessing and setting read only global variables
from a userspace control program through libbpf can only happen when
importing a BPF skeleton. Things like `bpf_object__find_map_by_name()`
are exposed but the name of this map is internal and
`internal_map_name()` is as well. Traversing through the maps array
via bpf_object directly doesn't seem possible either.

Why is this feature only available through generating a skeleton?
Should there be differences in supported functionality between using a
skeleton and using libbpf directly?

Re: Access to rodata when using libbpf directly

[Andrii Nakryiko]

On Wed, Apr 14, 2021 at 7:26 PM Grant Seltzer Richman
<grantseltzer@gmail.com> wrote:
>
> As I understand it, accessing and setting read only global variables
> from a userspace control program through libbpf can only happen when
> importing a BPF skeleton. Things like `bpf_object__find_map_by_name()`
> are exposed but the name of this map is internal and
> `internal_map_name()` is as well. Traversing through the maps array
> via bpf_object directly doesn't seem possible either.

Not really.

See bpf_object__for_each_map() macro and bpf_map__is_internal() API,
both of which are public. As for the name, it's also sort of part of
API, though I want to fix them in libbpf 1.0 (they should be named
.rodata, .data, .bss). So you can definitely either find the map with
iteration or by knowing how the name is generated. Then do mmap() and
using BTF you'll know each variable's offset and size. No magic, just
some code to do this, which is what is done by bpftool for skeletons
(bpftool is a completely external user of libbpf in this case, no
private APIs are involved).

>
> Why is this feature only available through generating a skeleton?
> Should there be differences in supported functionality between using a
> skeleton and using libbpf directly?

Re: Access to rodata when using libbpf directly

[Toke Høiland-Jørgensen]

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

> On Wed, Apr 14, 2021 at 7:26 PM Grant Seltzer Richman
> <grantseltzer@gmail.com> wrote:
>>
>> As I understand it, accessing and setting read only global variables
>> from a userspace control program through libbpf can only happen when
>> importing a BPF skeleton. Things like `bpf_object__find_map_by_name()`
>> are exposed but the name of this map is internal and
>> `internal_map_name()` is as well. Traversing through the maps array
>> via bpf_object directly doesn't seem possible either.
>
> Not really.
>
> See bpf_object__for_each_map() macro and bpf_map__is_internal() API,
> both of which are public. As for the name, it's also sort of part of
> API, though I want to fix them in libbpf 1.0 (they should be named
> .rodata, .data, .bss). So you can definitely either find the map with
> iteration or by knowing how the name is generated. Then do mmap() and
> using BTF you'll know each variable's offset and size. No magic, just
> some code to do this, which is what is done by bpftool for skeletons
> (bpftool is a completely external user of libbpf in this case, no
> private APIs are involved).

We also added bpf_map__set_initial_value() for this, so you don't even
need to mmap(); we're using this in libxdp:

https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/libxdp.c#L2325

-Toke