implement BPF_PROG_BIND_MAP

[florianl]

This PR implements the BPF_PROG_BIND_MAP functionality. While in general every map can be bind to a program, bpftool will only output and interpret data as metadata if the map meets some criteria:
https://github.com/torvalds/linux/blob/66f4beaa6c1d28161f534471484b2daa2de1dce0/tools/bpf/bpftool/prog.c#L212-L219

[lmb]

What has to happen to pick up the metadata from an ELF in libbpf style? Is it just "find a map with a specific name and bind it"? If yes, could you implement that? I'm asking because right now this is an API without a user inside the library itself, so I find it harder to evaluate.

[florianl]

The checks and limitations in kernel/bpf/syscall.c:bpf_prog_bind_map() just require a FD to a map and a loaded eBPF program.

bpftool adds some more requirements and strips the bpf_metadata_ prefix and requires the data to be in the .rodata section. Then a map is created with a single entry where the value of the first entry points to this BTF data.

#include <linux/bpf.h>

#ifndef SEC
	 #define SEC(NAME) __attribute__((section(NAME), used))
#endif

const char bpf_metadata_a[] SEC(".rodata") = "bar";
const int bpf_metadata_b SEC(".rodata") = 2;

SEC("cgroup_skb/egress")
int prog(struct xdp_md *ctx)
{
	return bpf_metadata_b ? 1 : 0;
}

char _license[] SEC("license") = "GPL";

The above shown code results in two metadata entries from one eBPF map entry:

$ sudo bpftool map dump id 123
[{
        "value": {
            ".rodata": [{
                    "bpf_metadata_a": "bar"
                },{
                    "bpf_metadata_b": 2
                }
            ]
        }
    }
]

and the corresponding bpftool output:

61: cgroup_skb  name prog  tag 57cd311f2e27366b  gpl
	loaded_at 2021-11-15T20:17:24+0100  uid 0
	xlated 16B  jited 18B  memlock 4096B  map_ids 123
	btf_id 7
	metadata:
		a = "bar"
		b = 2

While the bpftool output for metadata looks nice and pretty, I would not enforce the same requirements (prefix and .rodata section) here as well. Binding a map to a program allows to attach additional and individual information that might be unique and one can still dump the content of the map in other ways (also with bpftool map dump id X).

[lmb]

Makes sense. Follow up question: should we always bind .rodata if we have the appropriate syscall? Seems like that's the only thing necessary to support bpftool?

[florianl]

should we always bind .rodata if we have the appropriate syscall?

maybe a personal opinion but I don't think its a good idea to do so. E.g. to show the metadata bpftool requires the bpf_metadata_ prefix and just because something is located in .rodata it doesn't work automagically.

[lmb]

No, but having the map bound is a prerequisite for metadata to work if there is only metadata in the section. Thinking about it that will probably fail for other reasons though.