CO-RE (Compile Once - Run Everywhere) technology is more than a year old now. It allows observing systems’ structs through eBPF without installing kernel headers (kernel-devel package) & recompiling tools on every machine. It’s done by including premade & compressed debugging info directly into the kernel. This procedure requires compiling with the flag “CONFIG_DEBUG_INFO_BTF=y” enabled, and a kernel’s size increases only roughly up to 1.5 MB.
BPF is the future of Linux observability tooling, and CO-RE has incredibly reduced an overhead. Would it be possible to include the previously mentioned flag into Manjaro’s kernel building process?
More info here (remove spaces):
facebookmicrosites. github. io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html
I’m using kernel 5.10.42 which doesn’t seem to have BTF enabled (There is no entry for /sys/kernel/btf)
Should it be added to future 5.10.x versions or should I upgrade my kernel to have it?
That’s too bad.
The future of Linux is eBPF, and CO-RE is the future of eBPF.
I am maintaining an open source project named Tracee, which is eBPF based, and we are about to add CO-RE support to it. With CO-RE, the compiled binary will be able to run on kernels which have BTF enabled out of the box, just like a regular binary. Without it, the users will have to compile the bpf code with the kernel headers of the specific kernel it runs on.
Tracee is not the only project that will use CO-RE. Cilium is another example and more to come in the future.
Most major distros already have BTF enabled as @oji mentioned above, and by not enabling it now, I think that manjaro users (and I’m one of them) will be left behind.
If we look at Arch and our config of our kernel I see this:
--- config-Manjaro 2021-06-17 00:40:50.642243000 +0200
+++ config-Arch 2021-06-17 06:59:52.432230512 +0200
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/x86 5.12.7-2 Kernel Configuration
+# Linux/x86 5.12.11-arch1 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (GCC) 11.1.0"
CONFIG_CC_IS_GCC=y
@@ -260,7 +260,9 @@ CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
-# CONFIG_BPF_PRELOAD is not set
+CONFIG_USERMODE_DRIVER=y
+CONFIG_BPF_PRELOAD=y
+CONFIG_BPF_PRELOAD_UMD=m
CONFIG_USERFAULTFD=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_KCMP=y
@@ -449,7 +451,6 @@ CONFIG_X86_PMEM_LEGACY_DEVICE=y
CONFIG_X86_PMEM_LEGACY=m
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
-CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
@@ -10140,7 +10139,14 @@ CONFIG_DEBUG_BUGVERBOSE=y
#
# Compile-time checks and compiler options
#
-# CONFIG_DEBUG_INFO is not set
+CONFIG_DEBUG_INFO=y
+# CONFIG_DEBUG_INFO_REDUCED is not set
+# CONFIG_DEBUG_INFO_COMPRESSED is not set
+# CONFIG_DEBUG_INFO_SPLIT is not set
+# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
+CONFIG_DEBUG_INFO_DWARF4=y
+CONFIG_DEBUG_INFO_BTF=y
+# CONFIG_GDB_SCRIPTS is not set
CONFIG_FRAME_WARN=2048
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
So we may try it by not enabling the whole CONFIG_DEBUG_INFO if that is possible @nightmare-2021. However, it would be good that @yanivagman or @chendotjs try to modify the config file of one of our kernels, like linux512 and compile it locally on their systems to see the size
If someone from the community can be found who usually builds the kernel and the extramodules on Wednesdays and Saturdays, this is possible.
We will definitely not do this due to the additional time required.
@philm
I tested the kernel you compiled and it works great!
I don’t understand why adding CONFIG_DEBUG_INFO_BTF=y adds an extra of 120MB
From your commits I can see that you also included the CONFIG_DEBUG_INFO=y -
is this a must?
