libs
libs copied to clipboard
modpost failing message for bpf
Describe the bug
When building the bpf probe, I get the following make errors :point_down:
./include/linux/fortify-string.h:92:17: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign]
size_t p_len = __compiletime_strlen(p);
^~~~~~~~~~~~~~~~~~~~~~~
./include/linux/fortify-string.h:26:29: note: expanded from macro '__compiletime_strlen'
__ret = __builtin_strlen(__p); \
^~~
3 warnings generated.
MODPOST /usr/src/falco-39ae7d40496793cf3d3e7890c9bbdc202263836b/bpf/Module.symvers
scripts/mod/modpost: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by scripts/mod/modpost)
scripts/mod/modpost: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by scripts/mod/modpost)
make[2]: *** [scripts/Makefile.modpost:134: /usr/src/falco-39ae7d40496793cf3d3e7890c9bbdc202263836b/bpf/Module.symvers] Error 1
make[1]: *** [Makefile:1749: modules] Error 2
make[1]: Leaving directory '/host/lib/modules/5.18.3-arch1-1/build'
However, the bpf probe is built correctly. :thinking:
How to reproduce it
Option # 1
Run make from /usr/src/falco-39ae7d40496793cf3d3e7890c9bbdc202263836b/bpf.
Option # 2
docker run --rm -i -t \
--privileged \
-e FALCO_BPF_PROBE="" \
-v /boot:/host/boot:ro \
-v /lib/modules:/host/lib/modules:ro \
-v /usr:/host/usr:ro \
-v /etc:/host/etc:ro \
falcosecurity/falco-driver-loader:0.32.0
Expected behaviour
No errors.
(perhaps no MODPOST step?)
Screenshots
Environment
Libs version 39ae7d40496793cf3d3e7890c9bbdc202263836b
❯ uname -a
Linux x86 5.18.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 09 Jun 2022 16:14:10 +0000 x86_64 GNU/Linux
❯ uname -r
5.18.3-arch1-1
Additional context
/cc @Andreagit97 /cc @FedeDP /cc @jasondellaluce
Crazy stuff here :smile: I'll take a look at it!
This is the verbose output from a failed build in debian 10 (building in a container against host archlinux 5.18.x kernel):
$ make V=1
make -C /lib/modules/5.18.7-arch1-1/build M=$PWD
make: Entering directory '/lib/modules/5.18.7-arch1-1/build'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo >&2 ; \
/bin/false)
warning: the compiler differs from the one used to build the kernel
The kernel was built by: gcc (GCC) 12.1.0
You are using: gcc (Debian 8.3.0-6) 8.3.0
make -f ./scripts/Makefile.build obj=/libs/driver/bpf \
single-build= \
need-builtin=1 need-modorder=1
sh ./scripts/modules-check.sh /libs/driver/bpf/modules.order
make -f ./scripts/Makefile.modpost
sed 's/\.ko$/.prelink\.o/' /libs/driver/bpf/modules.order | scripts/mod/modpost -a -o /libs/driver/bpf/Module.symvers -e -i Module.symvers -N -T -
scripts/mod/modpost: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by scripts/mod/modpost)
scripts/mod/modpost: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by scripts/mod/modpost)
make[1]: *** [scripts/Makefile.modpost:134: /libs/driver/bpf/Module.symvers] Error 1
make: *** [Makefile:1753: modules] Error 2
make: Leaving directory '/lib/modules/5.18.7-arch1-1/build'
This is the same bpf module built on host:
$ make V=1
make -C /lib/modules/5.18.7-arch1-1/build M=$PWD
make: Entering directory '/lib/modules/5.18.7-arch1-1/build'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo >&2 ; \
/bin/false)
make -f ./scripts/Makefile.build obj=/home/federico/Work/libs/driver/bpf \
single-build= \
need-builtin=1 need-modorder=1
sh ./scripts/modules-check.sh /home/federico/Work/libs/driver/bpf/modules.order
make -f ./scripts/Makefile.modpost
make -f ./scripts/Makefile.modfinal
make: Leaving directory '/lib/modules/5.18.7-arch1-1/build'
Is this perhaps an incompatibility between host kernel/modpost script glibc and container one?
EDIT: it seems like modpost is called for host module too, but it is silent because it does not fail. Enabling make verbose will make it print though!
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
@FedeDP @Andreagit97
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
/help
@leogr: This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/help
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Could we reproduce again today given all the changes that happened?
@incertum It's actually not creating any error anymore, but it's still silently running underneath.
Indeed, if I run make V=1 as suggested by @FedeDP but with latest released version 5.0.1+driver, modpost is still there:
[root@x86 bpf]# make V=1
make -C /lib/modules/6.4.11-arch2-1/build M=$PWD
make -f ./scripts/Makefile.build obj=/usr/src/falco-5.0.1+driver/bpf need-builtin=1 need-modorder=1
# cmd_modules_order /usr/src/falco-5.0.1+driver/bpf/modules.order
{ :; } > /usr/src/falco-5.0.1+driver/bpf/modules.order
clang -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h \
-D__KERNEL__ -fmacro-prefix-map=./= \
\
\
-D__KERNEL__ \
-D__BPF_TRACING__ \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member \
-fno-jump-tables \
-fno-stack-protector \
-Wno-tautological-compare \
-O2 -g -emit-llvm -c /usr/src/falco-5.0.1+driver/bpf/probe.c -o /usr/src/falco-5.0.1+driver/bpf/probe.ll
In file included from /usr/src/falco-5.0.1+driver/bpf/probe.c:16:
In file included from ./include/linux/sched.h:12:
In file included from ./arch/x86/include/asm/current.h:9:
In file included from ./include/linux/cache.h:6:
In file included from ./arch/x86/include/asm/cache.h:5:
In file included from ./include/linux/linkage.h:8:
In file included from ./arch/x86/include/asm/linkage.h:6:
./arch/x86/include/asm/ibt.h:77:8: warning: 'nocf_check' attribute ignored; use -fcf-protection to enable the attribute [-Wignored-attributes]
extern __noendbr u64 ibt_save(bool disable);
^
./arch/x86/include/asm/ibt.h:32:34: note: expanded from macro '__noendbr'
#define __noendbr __attribute__((nocf_check))
^
./arch/x86/include/asm/ibt.h:78:8: warning: 'nocf_check' attribute ignored; use -fcf-protection to enable the attribute [-Wignored-attributes]
extern __noendbr void ibt_restore(u64 save);
^
./arch/x86/include/asm/ibt.h:32:34: note: expanded from macro '__noendbr'
#define __noendbr __attribute__((nocf_check))
^
2 warnings generated.
llc -march=bpf -filetype=obj -o /usr/src/falco-5.0.1+driver/bpf/probe.o /usr/src/falco-5.0.1+driver/bpf/probe.ll
sh ./scripts/modules-check.sh /usr/src/falco-5.0.1+driver/bpf/modules.order
make -f ./scripts/Makefile.modpost
# MODPOST /usr/src/falco-5.0.1+driver/bpf/Module.symvers
scripts/mod/modpost -a -N -o /usr/src/falco-5.0.1+driver/bpf/Module.symvers -n -T /usr/src/falco-5.0.1+driver/bpf/modules.order -i Module.symvers -e
make -f ./scripts/Makefile.modfinal
Notably, it also creates some module files in the same folder:
[root@x86 bpf]# ls -lha
total 6.5M
drwxr-xr-x 2 root root 4.0K Aug 24 12:55 .
drwxr-xr-x 3 root root 4.0K Jul 27 12:42 ..
-rw-r--r-- 1 root root 4.9K Jul 27 12:42 bpf_helpers.h
-rw-r--r-- 1 root root 592 Jul 27 12:42 builtins.h
-rw-r--r-- 1 root root 39K Jul 27 12:42 filler_helpers.h
-rw-r--r-- 1 root root 158K Jul 27 12:42 fillers.h
-rw-r--r-- 1 root root 1.9K Jul 27 12:42 Makefile
-rw-r--r-- 1 root root 2.5K Jul 27 12:42 maps.h
-rw-r--r-- 1 root root 620 Jul 27 12:42 missing_definitions.h
-rw-r--r-- 1 root root 0 Aug 24 12:55 modules.order
-rw-r--r-- 1 root root 114 Aug 24 12:55 .modules.order.cmd
-rw-r--r-- 1 root root 0 Aug 24 12:55 Module.symvers
-rw-r--r-- 1 root root 214 Aug 24 12:55 .Module.symvers.cmd
-rw-r--r-- 1 root root 16K Jul 27 12:42 plumbing_helpers.h
-rw-r--r-- 1 root root 7.2K Jul 27 12:42 probe.c
-rw-r--r-- 1 root root 2.6M Aug 24 12:55 probe.ll
-rw-r--r-- 1 root root 3.6M Aug 24 12:55 probe.o
-rw-r--r-- 1 root root 1.4K Jul 27 12:42 quirks.h
-rw-r--r-- 1 root root 2.8K Jul 27 12:42 ring_helpers.h
-rw-r--r-- 1 root root 6.5K Jul 27 12:42 types.h
I guess the root cause of this is :point_down:
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
...
all:
$(MAKE) -C $(KERNELDIR) M=$$PWD
By running make within the modules directory something intended for kernel modules happens in the make processing.
However, since we are almost sure now this has no side effects, I wouldn't consider this a bug anymore, just an aesthetic thing.
@falcosecurity/libs-maintainers If you don't see any possible problem with this, I'll close this issue.
Agree, we can close this one!
yeah this is not a top priority
Agreed, software can never be perfect. Closing as not planned to address for now.