You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was writing something to parse objects from a /sys/fs/bpf fs and was expecting to receive an error when using ebpf.LoadPinnedMap on a prog and ebpf.LoadPinnedProg on a map. Instead, the function properly returns a struct but with garbage data in each "wrong" case.
So I've looked into it, it seems that the kernel doesn't expose anything to know in advance, given a BPF pinned object file, if it's a map or a prog. When you stat such a file there's no way to know if it's going to be a BPF map or prog.
However, when you open such a file and you end up with a file descriptor, if you readlink this fd, you retrieve something like anon_inode:bpf-map or anon_inode:bpf-prog. See here for map fd for example. This, and reading /proc/self/fdinfo/<fd> allows you to discriminate, since you'll bump into fields named map_<...> for maps and prog_<...> for progs.
All of that to say that we could use the readlink tricks to return an error properly instead of bogus information from LoadPinnedMap or LoadPinnedProg, @dylandreimerink suggested adding this to the newProgramInfoFromFd for example, we could also do newMapInfoFromFd respectively:
On another topic, I think it would be great to have an API to parse objects indifferently if they are a map or a prog. A bit of what we can do right now with a "hack": reading everything, map and prog, as prog for example, since it doesn't return an error and then read common fields like memlock in fdinfo. It could be something like LoadPinned that would be common between maps and progs, and thus we could retrieve memlock using this object, or cast it into a map or prog if we want to go further.
I could elaborate on my use case and see if it makes sense but would love to know what people think :)!
The text was updated successfully, but these errors were encountered:
I was writing something to parse objects from a
/sys/fs/bpf
fs and was expecting to receive an error when usingebpf.LoadPinnedMap
on a prog andebpf.LoadPinnedProg
on a map. Instead, the function properly returns a struct but with garbage data in each "wrong" case.So I've looked into it, it seems that the kernel doesn't expose anything to know in advance, given a BPF pinned object file, if it's a map or a prog. When you
stat
such a file there's no way to know if it's going to be a BPF map or prog.However, when you open such a file and you end up with a file descriptor, if you
readlink
this fd, you retrieve something likeanon_inode:bpf-map
oranon_inode:bpf-prog
. See here for map fd for example. This, and reading/proc/self/fdinfo/<fd>
allows you to discriminate, since you'll bump into fields namedmap_<...>
for maps andprog_<...>
for progs.All of that to say that we could use the
readlink
tricks to return an error properly instead of bogus information fromLoadPinnedMap
orLoadPinnedProg
, @dylandreimerink suggested adding this to thenewProgramInfoFromFd
for example, we could also donewMapInfoFromFd
respectively:ebpf/info.go
Line 149 in 88736f4
ebpf/info.go
Line 54 in 88736f4
On another topic, I think it would be great to have an API to parse objects indifferently if they are a map or a prog. A bit of what we can do right now with a "hack": reading everything, map and prog, as prog for example, since it doesn't return an error and then read common fields like
memlock
in fdinfo. It could be something likeLoadPinned
that would be common between maps and progs, and thus we could retrievememlock
using this object, or cast it into a map or prog if we want to go further.I could elaborate on my use case and see if it makes sense but would love to know what people think :)!
The text was updated successfully, but these errors were encountered: