How to get access to .bss map?

[mscastanho]

I have an application originally written using libbpf that I have been gradually porting to cilium/ebpf. It uses some global variables to modify the eBPF (XDP) application's behavior after it has been loaded to the kernel. This can be done both by the main userspace daemon managing the program (in which case the new Variables concept works fine), or by separate processes, like CLI calls that load the .bss map from the BPF filesystem (previously pinned) and alter program configurations directly.

With libbpf, the skeleton exposes a handle to the .bss map, so it's easy to pin it to the filesystem during program load and setup.

But apparently this is not as simple to do with cilium/ebpf, because bpf2go does not expose .bss to the generated spec.

So AFAIU, the pseudo-code bellow represents the steps I have to follow to get a handle to the .bss map and pin it to the filesystem using cilium/ebpf (assuming this is done by the program that originally loaded the XDP program to the kernel using):

// Get program info
pinfo, err := prog.Info()
...

// Access list of maps used by the program
mids, err := pinfo.MapIDs()
...

// Iterate over the list of maps to find the one I want
for _, mid := range mids {
      m, err := ebpf.NewMapFromID(mid)
      ...

      // Get info to check the map's name
      minfo, err := m.Info()
      ...

      if minfo.Name == ".bss" {
            // found it! 
            // pin the map
      }
      m.Close()  
}

Is this really the way to implement this use case today? Or is there a simpler approach?

[ti-mo]

Hi Matheus, good question! If I understand your post correctly, your problem stems mostly from trying to manage global variables using external tools, right?

In that case, as an aside, you can specify an ELF section of your choosing when declaring globals: uint32_t global_var __section(".data.myconfig");. This is really useful for dividing globals into categories. It'll also result in more predictable behaviour compared to relying on .bss, since the compiler typically puts any zero-initialized variable there, including static vars with local scope.

Now, if you specify a default value for a global in your C code (uint32_t global_var = 42), it'll suddenly appear in .data instead of .bss, breaking your mechanism. Explicitly emitting your variables to a specific section is the way to go here. Just make sure whatever section name you choose is prefixed by .data (or .rodata for global consts) in order for ebpf-go to find it. However, even with this change, bpf2go still won't emit an *ebpf.Map field for it.

I often recommend bpf2go users they declare custom structs to pass to LoadAndAssign (which is what bpf2go uses underlyingly). In your case, something like the following should work:

type objs struct {
	XDPEntry *ebpf.Program `ebpf:"xdp_entry"`
	Config *ebpf.Map `ebpf:".data.config"`
	SomeMap *ebpf.Map `ebpf:"some_map"`
}

Typically, looking at Cilium at least, we have dozens of maps and programs in any given Collection, but we only interact with a few of them at load time, like attaching entrypoints to some xdp or tc hooks. Most maps are declared with LIBBPF_PIN_BY_NAME and accessed by other parts of the agent using the pin. Most other programs are tail calls and are inserted into prog arrays automatically. Only the few objects we interact with are mentioned in objs, everything else gets lazy-loaded and closed automatically.

If you don't want to maintain this struct definition yourself due to its size, you can also opt for ebpf.NewCollection and access Collection.Maps[".data.config"] as needed, but then you won't benefit from lazy-loading -- though if you were using the vanilla bpf2go objs structs, there won't be much difference anyway.

Hope this helps!

[mscastanho]

Thanks for the explanation @ti-mo! This indeed helped.

By explicitly defining the ebpf-tagged fields in my struct and relying on lazy loading I was able to get easy access to .bss and pin it to bpffs.

For now renaming it to .data.config or something else is not doable because other parts of my code are still relying on it being called .bss, but it's good to know that's a possibility. I agree it makes the clode more organized and less error-prone. I'll save it for a future refactoring.