The Linux eBPF syscall (https://docs.kernel.org/userspace-api/ebpf/syscall.html) BPF_OBJ_GET_INFO_BY_FD type may populate multiple data formats based on the eBPF object type. The bpf_btf_info datatype contains a pointer which points to another block of memory which is populated. The coregrind linux syswrap handler does not account for that memory being written to by the kernel and thus properly initialized. OBSERVED RESULT Running valgrind against a program which executes these syscalls and uses the results will return a large number of errors such as "Conditional jump or move depends on uninitialised value(s)". EXPECTED RESULT No incorrect errors are returned. SOFTWARE/OS VERSIONS ADDITIONAL INFORMATION
In bpf_obj_get_info_size we only handle if (VG_(strstr)(buf, "prog_type:")) return sizeof(struct vki_bpf_prog_info); if (VG_(strstr)(buf, "map_type:")) return sizeof(struct vki_bpf_map_info); return 0; Looks like we are missing btf_info and link_info.
Created attachment 164374 [details] untested patch Could you test this patch?
Looks like this is a can of worms. There are a lot of commands and struct members that are missing (comparing Fedora 29 and Valgrind hit HEAD). I tried sudo valgrind bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }' from https://brendangregg.com/ebpf.html and I got quite a few string-related errors, two bpf unhandled commands and some uninit BPF syscall parameters.
Created attachment 168308 [details] Handle btf_info for BPF_OBJ_GET_INFO_BY_FD syscall. The eBPF syscall documented here: https://docs.kernel.org/userspace-api/ebpf/syscall.html has a subtype of BPF_OBJ_GET_INFO_BY_FD which gets information about something based on the file descriptor passed in. The types of data structures used vary based on the type of object the file descriptor refers to. The definition of enum bpf_obj_type is a copy of the data structure used in the kernel bpftool here: https://elixir.bootlin.com/linux/v6.6.7/source/tools/bpf/bpftool/main.h#L67 Note that though the definition for BPF_OBJ_LINK was included for completeness, handling of that subtype was not implemented here and the existing behavior remains.