netdev - Re: [QUESTION] bpf, iproute2/tc: verifier fails because of a map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 7 Feb 2023 20:43:17 +0100
From:   Justin Iurman <justin.iurman@...ege.be>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [QUESTION] bpf, iproute2/tc: verifier fails because of a map

On 2/7/23 19:31, Alexei Starovoitov wrote:
> On Tue, Feb 7, 2023 at 3:09 AM Justin Iurman <justin.iurman@...ege.be> wrote:
>>
>> Hello,
>>
>> CC'ing netdev as well, since I initially suspected an issue in iproute2.
>> However, after having recompiled iproute2 with libbpf, I'm still stuck
>> facing the same problem.
>>
>> Environment:
>>    - OS: Ubuntu 20.04.5 LTS
>>    - kernel: 5.4.0-137-generic x86_64 (CONFIG_DEBUG_INFO_BTF=y)
>>    - clang version 10.0.0-4ubuntu1
>>    - iproute2-6.1.0, libbpf 1.2.0 (iproute2-ss200127 installed by default
>> without libbpf)
>>
>> Note: same result with kernel 6.2.0-rc6+ (net-next), as a test to be
>> aligned with latest iproute2 version (just in case).
>>
>> Long story short: I can't for the life of me make the ebpf program load
>> correctly with tc. What's the cause? Well, a map, and the verifier
>> doesn't like it. I must definitely be doing something wrong, but can't
>> find what. Here is a reproducible and minimal example:
>>
>> #include "vmlinux.h"
>> #include <bpf/bpf_helpers.h>
>>
>> #define TC_ACT_OK 0
>> #define MAX_BYTES 2048
>>
>> char _license[] SEC("license") = "GPL";
>>
>> struct mystruct_t {
>>          __u8 bytes[MAX_BYTES];
>> };
>>
>> struct {
>>          __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
>>          __uint(key_size, sizeof(__u8));
>>          __uint(value_size, sizeof(struct mystruct_t));
>>          __uint(max_entries, 1);
>> } percpu_map SEC(".maps");
>>
>> SEC("egress")
>> int xxx(struct __sk_buff *skb)
>> {
>>          __u8 idx = 0;
>>          struct mystruct_t *x = bpf_map_lookup_elem(&percpu_map, &idx);
>>          return TC_ACT_OK;
>> }
>>
>>
>> Here is how I compile the whole thing:
>>
>> git clone --recursive --depth 1 https://github.com/libbpf/libbpf
>> ./deps/libbpf
>> make -j -C deps/libbpf/src/ BUILD_STATIC_ONLY=y DESTDIR="build"
>> INCLUDEDIR= LIBDIR= UAPIDIR= install
>>
>> git clone --recursive --depth 1 https://github.com/libbpf/bpftool
>> ./deps/bpftool
>> make -j -C deps/bpftool/src/
>> deps/bpftool/src/bpftool btf dump file /sys/kernel/btf/vmlinux format c
>>   > build/vmlinux.h
>>
>> clang -g -O2 -Wall -Wextra -target bpf -D__TARGET_ARCH_x86_64 -I build/
>> -c program.c -o build/program.o
>>
>>
>> I noticed that "clang-bpf-co-re" is OFF when compiling bpftool, don't
>> know if it's part of the problem or not. Here is what the "build"
>> directory looks like after that:
>>
>> $ ls -al build
>> [...]
>> drwxr-xr-x 2 justin justin    4096 fév  6 18:20 bpf
>> -rw-rw-r-- 1 justin justin 3936504 fév  6 18:20 libbpf.a
>> drwxr-xr-x 2 justin justin    4096 fév  6 18:20 pkgconfig
>> -rw-rw-r-- 1 justin justin   10592 fév  7 10:42 program.o
>> -rw-rw-r-- 1 justin justin 2467774 fév  7 10:42 vmlinux.h
>>
>>
>> And here is the verifier error I got when loading it with tc (qdisc
>> clsact already attached):
>>
>> $ sudo ../deps/iproute2/tc/tc filter add dev eno2 egress bpf da obj
>> program.o sec egress
>>
>> libbpf: map 'percpu_map': failed to create: Invalid argument(-22)
>> libbpf: failed to load object 'program.o'
>> Unable to load program
> 
> It's likely due to
> __uint(key_size, sizeof(__u8));
> 
> https://docs.kernel.org/bpf/map_array.html
> "The key type is an unsigned 32-bit integer (4 bytes) and the map is
> of constant size."

Sigh... don't know if I should laugh or cry. Thanks!