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
During the ARM porting effort, I ran into inexplicable behaviour of
BPF_PROG_LOAD on alarm kernel 5.5.10 and up. (when I switched to linux-armv7)
It would constantly return -EINVAL, which the manpage describes as follows:
For BPF_PROG_LOAD, indicates an attempt to load an invalid
program. eBPF programs can be deemed invalid due to
unrecognized instructions, the use of reserved fields, jumps
out of range, infinite loops or calls of unknown functions.
All cases were ruled out. All jumps were removed from the program, I could not
spot any unrecognized instructions (cilium/ebpf could dump the assembly
perfectly), I could not validate the usage of reserved fields, nor what
'reserved field' really meant. It did not contain any loops or function calls.
Eventually, I stumbled upon the CONFIG_BPF_EVENTS kernel config. This config
was missing on the armv7 kernel I was running, but it was present on the
kernel running on my RPi. This setting registers the BPF_PROG_TYPE_KPROBE
program type in the kernel. Since the kernel did not know the type, the syscall
would return -EINVAL.
I dug into this and found the following critical kernel configs:
CONFIG_BPF: the BPF VM needs to be present
CONFIG_BPF_SYSCALL: the bpf() syscall needs to be present
CONFIG_BPF_EVENTS: bpf(BPF_PROG_LOAD... will return -EINVAL since BPF_PROG_TYPE_KPROBE is not registered.
CONFIG_KPROBE_EVENTS: kprobes cannot be attached to perf events
After realizing this, I built and ran bpftool, and sure enough..
During the ARM porting effort, I ran into inexplicable behaviour of
BPF_PROG_LOAD on alarm kernel 5.5.10 and up. (when I switched to
linux-armv7
)It would constantly return
-EINVAL
, which the manpage describes as follows:All cases were ruled out. All jumps were removed from the program, I could not
spot any unrecognized instructions (
cilium/ebpf
could dump the assemblyperfectly), I could not validate the usage of reserved fields, nor what
'reserved field' really meant. It did not contain any loops or function calls.
Eventually, I stumbled upon the
CONFIG_BPF_EVENTS
kernel config. This configwas missing on the armv7 kernel I was running, but it was present on the
kernel running on my RPi. This setting registers the
BPF_PROG_TYPE_KPROBE
program type in the kernel. Since the kernel did not know the type, the syscall
would return -EINVAL.
I dug into this and found the following critical kernel configs:
CONFIG_BPF
: the BPF VM needs to be presentCONFIG_BPF_SYSCALL
: thebpf()
syscall needs to be presentCONFIG_BPF_EVENTS
:bpf(BPF_PROG_LOAD...
will return -EINVAL since BPF_PROG_TYPE_KPROBE is not registered.CONFIG_KPROBE_EVENTS
: kprobes cannot be attached to perf eventsAfter realizing this, I built and ran
bpftool
, and sure enough..With the tool's output, as a result:
Inspect
/proc/config.gz
or equivalent in/boot/
for kernel flags that are known to impact the functionality of the tool.The ELF build system contains a list of kernel configs that are set on the kernel trees during probe build time. Those could also be checked.
The text was updated successfully, but these errors were encountered: