__kconfig can not be used < 5.2

[g0dA]

when i load ebpf program occur error:

resolve .kconfig: creating map: map create: read- and write-only maps not supported (requires >= v5.2)

this error from

ebpf/map.go

Line 451 in 01ebd4c

if haveFeatErr := haveMapMutabilityModifiers(); haveFeatErr != nil {

in my code

extern int LINUX_KERNEL_VERSION __kconfig;

__kconfig is defined in bpf_helpers.h

#define __kconfig __attribute__((section(".kconfig")))

the section .kconfig is set as unix.BPF_F_RDONLY_PROG

ebpf/elf_reader.go

Lines 1139 to 1149 in 01ebd4c

	ec.kconfig = &MapSpec{
	Name: ".kconfig",
	Type: Array,
	KeySize: uint32(4),
	ValueSize: ds.Size,
	MaxEntries: 1,
	Flags: unix.BPF_F_RDONLY_PROG | unix.BPF_F_MMAPABLE,
	Freeze: true,
	Key: &btf.Int{Size: 4},
	Value: ds,
	}

so, can i rewrite .kconfig flag or have other ways to use __kconfig when kernel < 5.2

[florianl]

hi 👋

haveMapMutabilityModifiers() does not perform a check against a specific Linux kernel version, but tries to create a map with the specified attribute. If this probe does not succeed, ErrNotSupported is returned and hints to the point, that the used Linux kernel does not provide this feature. requires >= v5.2 is mentioned in the returned error message as this is the Linux kernel version, when this particular feature was added to the Linux kernel. But as Linux kernel features can be backported, older Linux kernel might succeed with this probe.

Did you try to run your program on other system with other Linux kernels? Which Linux kernels did you test?

[g0dA]

haveMapMutabilityModifiers() does not perform a check against a specific Linux kernel version, but tries to create a map with the specified attribute

yes, you are right, but haveMapMutabilityModifiers() tries to create a map with unix.BPF_F_RDONLY_PROG and haveMmapableMaps() creates map with unix.BPF_F_MMAPABLE

BPF_F_RDONLY_PROG was introduced in kernel v5.2, patch is [PATCH bpf-next v6 03/16] bpf: add program side {rd, wr}only support for maps

BPF_F_MMAPABLE was introduced in kernel v5.5

so, when .kconfig was set unix.BPF_F_RDONLY_PROG | unix.BPF_F_MMAPABLE, according to the kernel capability, it is indeed impossible to use below 5.2

But as Linux kernel features can be backported, older Linux kernel might succeed with this probe.

it is right too, but it's not a common phenomenon, so when i want to use CO-RE on kernel < 5.2, always go wrong : (

Did you try to run your program on other system with other Linux kernels? Which Linux kernels did you test?

i try it on Ubuntu 20.04 LTS with kernel 5.4.0-77-generic and CentOS Linux 7 (Core) with kernel 3.10.0-1127.19.1.el7.x86_64, they can not pass map create check

Of course, I can run my ebpf program perfectly on my Arch Linux with kernel 6.4.10-arch1-1

[florianl]

If I follow correctly, you are targeting kernels between 5.2 and 5.5.

Reading up on .kconfig I think simply overwriting the flags of this special map will not do the job. libbpf/libbpf@3cd45b6 explains, why BPF_F_MMAPABLE is required in some cases for this special map. Differentiating these kind of special cases is currently not implemented in cilium/ebpf.

[g0dA]

Yes, this caused __kconfig not to work properly below v5.2/v5.5

I found that cilium/ebpf has the ability RewriteConstants() to rewrite global constants, but this function will only look for constants in .rodata, and .rodata is also unix.BPF_F_RDONLY_PROG, which cannot be found in Normal use under v5.2

So is there a way to create a version constant that is not in .rodata, and then override it on load?

[ti-mo]

FYI, 3.10.x is absolutely ancient and has very limited bpf support in general. If you want to use ebpf in any serious capacity today, you'll want to target at least 4.18 (or 4.19, it's LTS) for BTF support.

Since ebpf-go doesn't really facilitate the user space side of mmapable maps, I guess we should drop setting BPF_F_MMAPABLE on .kconfig by default for now. (@rgo3) They're going to be more useful from libbpf-based C projects since structs can be shared across the user space and bpf C programs. In Go, you'd need to be careful aligning C and Go struct layouts, and things like bitfields aren't even supported by the language itself, so that complicates matters a bit. There's no reason mmapable maps couldn't be supported eventually, though.

BPF_F_RDONLY_PROG is set on a map to indicate to the verifier that its contents are immutable after loading, enabling JIT optimizations and branch elimination. You could remove that flag as well, but the compiler will still emit direct map access instructions (introduced in https://lore.kernel.org/bpf/20190409210910.32048-2-daniel@iogearbox.net/) that are only supported as of kernel 5.2.

One alternative is devising your own global data approach like we've done in Cilium: https://github.com/cilium/cilium/blob/c7ce64e90116b873c59e6b7195dabd117a26c978/pkg/bpf/collection.go#L236. This replaces all direct map loads with imm64s, embedding all values into the bytecode itself. You'll need to access your .kconfig variables in a specific way from C to get the compiler to do what you want. Here be dragons, you're on your own for this one. 🙂

[g0dA]

FYI, 3.10.x is absolutely ancient and has very limited bpf support in general. If you want to use ebpf in any serious capacity today, you'll want to target at least 4.18 (or 4.19, it's LTS) for BTF support.

Yes, but I have a reason to use ebpf on 3.10, so I used https://github.com/aquasecurity/btfhub to help me complete the support of btf

You'll need to access your .kconfig variables in a specific way from C to get the compiler to do what you want.

I think I have solved the problem of judging the kernel version, but now I have a new problem, that is, is it not very good for struct flavor in cilium/ebpf? I always have problems : (