-
Notifications
You must be signed in to change notification settings - Fork 721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
program: relocation of program targeting a module fails if CONFIG_DEBUG_INFO_BTF_MODULES is disabled #1436
Comments
Thanks for the detailed report. @brycekahle maybe this is as easy as not generating an error if module BTF doesn't exist? |
Yeah, that would probably work. If the program needs the module BTF then the CO-RE relocations will fail and poison the instructions. That error is a little harder to debug, but will still fail regardless. |
The fix is going to be here somewhere: Lines 149 to 155 in 7719d2f
@orishuss are you up for contributing a fix? We can probably test this by using a bogus |
In kernels where the flag CONFIG_DEBUG_INFO_BTF_MODULES is not set, including kernels 5.10 and below (because the flag was introduced in 5.11), loading a program that attaches to kernel module functions and relied on CORE failed because the module's BTF is not available. This fix allows the program to run, obviously only as long as it only relies on the kernel's BTF and not on the specific module's BTF. Fixes: cilium#1436 Signed-off-by: Ori Shussman <[email protected]>
In kernels where the flag CONFIG_DEBUG_INFO_BTF_MODULES is not set, including kernels 5.10 and below (because the flag was introduced in 5.11), loading a program that attaches to kernel module functions and relied on CORE failed because the module's BTF is not available. This fix allows the program to run, obviously only as long as it only relies on the kernel's BTF and not on the specific module's BTF. Fixes: cilium#1436 Signed-off-by: Ori Shussman <[email protected]>
In kernels where the flag CONFIG_DEBUG_INFO_BTF_MODULES is not set, including kernels 5.10 and below (because the flag was introduced in 5.11), loading a program that attaches to kernel module functions and relied on CORE failed because the module's BTF is not available. This fix allows the program to run, obviously only as long as it only relies on the kernel's BTF and not on the specific module's BTF. Fixes: #1436 Signed-off-by: Ori Shussman <[email protected]>
Describe the bug
Support for btf parsing of kernel modules, recently introduced, was long awaited, but I believe it breaks some bpf programs. The programs affected are ones that are attached to loaded kernel module functions, on certain systems according to kernel configuration.
CONFIG_DEBUG_INFO_BTF_MODULES
is a kernel flag, introduced in kernel5.11
, that makes the btf files for kernel modules appear in/sys/kernel/btf
. The machine on which I encountered the error is kernel5.10
which explains why this bug happens, but the same should happen on newer kernels if the flag is not set.A practical solution could be to make the dependence on the module's specific btf file optional (so that, for example, if
/sys/kernel/btf/nf_conntrack_netlink
doesn't exist, it just skips it). This way, the module could still use CORE relocations for normal vmlinux structs.Notice that changing the section name (for example
SEC("kprobe/ctnetlink_fill_info")
toSEC("kprobe/ctnetlink_fill_info_")
) "fixes" the problem because it makes the library only checkvmlinux
btf, as it can't find what module loaded the function.Commands outputs
kernel version
5.10.213
package version
github.com/cilium/ebpf v0.14.0
missing btf file for module:
kernel module is indeed loaded:
kallsyms (where the module name of the function comes from):
Output difference between version 0.12.3 and 0.14.0 (the version of the package is the only thing that was changed)
How to reproduce
use
make
and run./kmerror
on a machine that is misconfiguredkmerror.zip
The text was updated successfully, but these errors were encountered: