BUG: bpf tests fail on aarch64

[pcmoore]

The bpf tests fail on aarch64 because the test's bpf program fails with EPERM, even run as root on a system with SELinux in permissive mode. The failure does not occur on a similarly configured x86_64 system.
Here is a strace of the bpf program on a Fedora Rawhide aarch64 system:

# strace ./bpf
execve("./bpf", ["./bpf"], 0xffffd43251e0 /* 28 vars */) = 0
brk(NULL)                               = 0xeb27000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=35846, ...}) = 0
mmap(NULL, 35846, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffb37a9000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\20C\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=3036328, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffb37a7000
mmap(NULL, 1530744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffffb35ff000
mprotect(0xffffb375a000, 73728, PROT_NONE) = 0
mmap(0xffffb376c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15d000) = 0xffffb376c000
mmap(0xffffb3772000, 11128, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffffb3772000
close(3)                                = 0
mprotect(0xffffb376c000, 12288, PROT_READ) = 0
mprotect(0x41f000, 4096, PROT_READ)     = 0
mprotect(0xffffb37b4000, 4096, PROT_READ) = 0
munmap(0xffffb37a9000, 35846)           = 0
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_SOCKET_FILTER, insn_cnt=2, insns=0xffffe2d64bc0, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(0, 0, 0), prog_flags=0, prog_name="", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS, prog_btf_fd=0, func_info_rec_size=0, func_info=NULL, func_info_cnt=0, line_info_rec_size=0, line_info=NULL, line_info_cnt=0, attach_btf_id=0, attach_prog_fd=0}, 120) = -1 EPERM (Operation not permitted)
exit_group(-1)                          = ?
+++ exited with 255 +++

[pcmoore]

@olsajiri can you take a look at this?

[pcmoore]

After looking through the kernel code, and playing around some today, it appears the problem lies in bpf_prog_charge_memlock() and RLIMIT_MEMLOCK. On both my x86_64 and aarch64 test systems it appears that the RLIMIT_MEMLOCK is 64kb, however on my aarch64 system that doesn't appear to be enough, but 128kb seems sufficient:

# uname -m
aarch64
# uname -r
5.6.0-0.rc5.git0.1.1.secnext.fc33.aarch64
# ulimit -l
64
# ./bpf; echo $?
255
# ulimit -l 128
# ./bpf; echo $?
0

... it looks like the fix is to make sure we bump RLIMIT_MEMLOCK to at least 128kb before calling bpf().

[pcmoore]

This should be fixed via 2067663.

[olsajiri]

I'm still in the process of getting some functional aarch64 machine for testing
but that looks like good explanation.. will check, thanks

ok, now it says, you fixed that.. cool, thanks again ;-)