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:   Mon, 3 Aug 2020 21:31:50 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v5 bpf-next 3/4] bpf: Add kernel module with user mode
 driver that populates bpffs.

On 8/3/20 8:33 PM, Alexei Starovoitov wrote:
> On Mon, Aug 3, 2020 at 10:40 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>>
>> On 8/3/20 7:34 PM, Daniel Borkmann wrote:
>>> On 8/3/20 7:15 PM, Daniel Borkmann wrote:
>>>> On 8/3/20 12:29 AM, Alexei Starovoitov wrote:
>>>>> From: Alexei Starovoitov <ast@...nel.org>
>>>>>
>>>>> Add kernel module with user mode driver that populates bpffs with
>>>>> BPF iterators.
>>>>>
>>>>> $ mount bpffs /my/bpffs/ -t bpf
>>>>> $ ls -la /my/bpffs/
>>>>> total 4
>>>>> drwxrwxrwt  2 root root    0 Jul  2 00:27 .
>>>>> drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
>>>>> -rw-------  1 root root    0 Jul  2 00:27 maps.debug
>>>>> -rw-------  1 root root    0 Jul  2 00:27 progs.debug
>>>>>
>>>>> The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
>>>>> maps, load two BPF programs, attach them to BPF iterators, and finally send two
>>>>> bpf_link IDs back to the kernel.
>>>>> The kernel will pin two bpf_links into newly mounted bpffs instance under
>>>>> names "progs.debug" and "maps.debug". These two files become human readable.
>>>>>
>>>>> $ cat /my/bpffs/progs.debug
>>>>>     id name            attached
>>>>>     11 dump_bpf_map    bpf_iter_bpf_map
>>>>>     12 dump_bpf_prog   bpf_iter_bpf_prog
>>>>>     27 test_pkt_access
>>>>>     32 test_main       test_pkt_access test_pkt_access
>>>>>     33 test_subprog1   test_pkt_access_subprog1 test_pkt_access
>>>>>     34 test_subprog2   test_pkt_access_subprog2 test_pkt_access
>>>>>     35 test_subprog3   test_pkt_access_subprog3 test_pkt_access
>>>>>     36 new_get_skb_len get_skb_len test_pkt_access
>>>>>     37 new_get_skb_ifindex get_skb_ifindex test_pkt_access
>>>>>     38 new_get_constant get_constant test_pkt_access
>>>>>
>>>>> The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
>>>>> all BPF programs currently loaded in the system. This information is unstable
>>>>> and will change from kernel to kernel as ".debug" suffix conveys.
>>>>>
>>>>> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
>>>> [...]
>>>>> diff --git a/kernel/bpf/preload/Kconfig b/kernel/bpf/preload/Kconfig
>>>>> new file mode 100644
>>>>> index 000000000000..b8ba5a9398ed
>>>>> --- /dev/null
>>>>> +++ b/kernel/bpf/preload/Kconfig
>>>>> @@ -0,0 +1,18 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>> +menuconfig BPF_PRELOAD
>>>>> +    bool "Preload BPF file system with kernel specific program and map iterators"
>>>>> +    depends on BPF
>>>>> +    help
>>>>> +      This builds kernel module with several embedded BPF programs that are
>>>>> +      pinned into BPF FS mount point as human readable files that are
>>>>> +      useful in debugging and introspection of BPF programs and maps.
>>>>> +
>>>>> +if BPF_PRELOAD
>>>>> +config BPF_PRELOAD_UMD
>>>>> +    tristate "bpf_preload kernel module with user mode driver"
>>>>> +    depends on CC_CAN_LINK
>>>>> +    depends on m || CC_CAN_LINK_STATIC
>>>>> +    default m
>>>>> +    help
>>>>> +      This builds bpf_preload kernel module with embedded user mode driver.
>>>>> +endif
>>>> [...]
>>>> When I applied this set locally to run build & selftests I noticed that the above
>>>> kconfig will appear in the top-level menuconfig. This is how it looks in menuconfig:
>>>>
>>>>     │ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
>>>>     │ │                                           General setup  --->                                                                                      │ │
>>>>     │ │                                       [*] 64-bit kernel                                                                                            │ │
>>>>     │ │                                           Processor type and features  --->                                                                        │ │
>>>>     │ │                                           Power management and ACPI options  --->                                                                  │ │
>>>>     │ │                                           Bus options (PCI etc.)  --->                                                                             │ │
>>>>     │ │                                           Binary Emulations  --->                                                                                  │ │
>>>>     │ │                                           Firmware Drivers  --->                                                                                   │ │
>>>>     │ │                                       [*] Virtualization  --->                                                                                     │ │
>>>>     │ │                                           General architecture-dependent options  --->                                                             │ │
>>>>     │ │                                       [*] Enable loadable module support  --->                                                                     │ │
>>>>     │ │                                       -*- Enable the block layer  --->                                                                             │ │
>>>>     │ │                                           IO Schedulers  --->                                                                                      │ │
>>>>     │ │                                       [ ] Preload BPF file system with kernel specific program and map iterators  ----                             │ │
>>>>     │ │                                           Executable file formats  --->                                                                            │ │
>>>>     │ │                                           Memory Management options  --->                                                                          │ │
>>>>     │ │                                       [*] Networking support  --->                                                                                 │ │
>>>>     │ │                                           Device Drivers  --->                                                                                     │ │
>>>>     │ │                                           File systems  --->                                                                                       │ │
>>>>     │ │                                           Security options  --->                                                                                   │ │
>>>> [...]
>>>>
>>>> I assume the original intention was to have it under 'general setup' on a similar level for
>>>> the JIT settings, or is this intentional to have it at this high level next to 'networking
>>>> support' and others?
> 
> I don't remember when last time I did menuconfig.
> How do you propose to move it?
> Any particular suggestion how kconfig suppose to look like?

See the init/Kconfig e.g. BPF_JIT_ALWAYS_ON. This is under `menu "General setup"`. One option
is to move it there too. OT: independent of this, maybe in next cycle it would make sense to add
a BPF subcategory under 'general setup' where we place all the BPF related items including the JIT
which is still under networking. Given there are more and more BPF kconfig knobs that would improve
the user experience a bit as well.

>>> Hm, my config has:
>>>
>>> CONFIG_BPF_PRELOAD=y
>>> CONFIG_BPF_PRELOAD_UMD=y
>>>
>>> I'm getting the following 3 warnings and build error below:
>>>
>>> root@...k:~/bpf-next# make -j8 > /dev/null
>>> arch/x86/hyperv/hv_apic.c: In function ‘hv_send_ipi_mask_allbutself’:
>>> arch/x86/hyperv/hv_apic.c:236:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>    }
>>>    ^
>>> make[3]: *** No rule to make target 'kernel/bpf/preload/./../../tools/lib/bpf/bpf.c', needed by 'kernel/bpf/preload/./../../tools/lib/bpf/bpf.o'.  Stop.
>>> make[3]: *** Waiting for unfinished jobs....
>>> kernel/bpf/preload/iterators/iterators.c: In function ‘main’:
>>> kernel/bpf/preload/iterators/iterators.c:50:2: warning: ignoring return value of ‘dup’, declared with attribute warn_unused_result [-Wunused-result]
>>>     dup(debug_fd);
>>>     ^~~~~~~~~~~~~
>>> kernel/bpf/preload/iterators/iterators.c:53:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
>>>     read(from_kernel, &magic, sizeof(magic));
>>>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> kernel/bpf/preload/iterators/iterators.c:85:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
>>>     read(from_kernel, &magic, sizeof(magic));
>>>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> make[2]: *** [kernel/bpf/preload] Error 2
>>> make[1]: *** [kernel/bpf] Error 2
>>> make: *** [kernel] Error 2
>>> make: *** Waiting for unfinished jobs....
>>> [...]
>>>
>>> Have you seen the target error before, what am I missing?
>>
>> Looks like the path in this patch is wrong:
>>
>> diff --git a/kernel/bpf/preload/Makefile b/kernel/bpf/preload/Makefile
>> index 191d82209842..136c6ca0c196 100644
>> --- a/kernel/bpf/preload/Makefile
>> +++ b/kernel/bpf/preload/Makefile
>> @@ -1,6 +1,6 @@
>>    # SPDX-License-Identifier: GPL-2.0
>>
>> -LIBBPF := $(srctree)/../../tools/lib/bpf
>> +LIBBPF := $(srctree)/../../../tools/lib/bpf
> 
> hmm. that's very odd.
> Are you building in-src-tree ?

Yes, I always build in src tree. Odd.

> I'm building out-of-src-tree with KBUILD_OUTPUT.
> And two pairs of dots would be correct.
> make V=1 kernel/bpf/preload/
> gcc  -m64 -lelf -lz  -o kernel/bpf/preload/bpf_preload_umd
> kernel/bpf/preload/iterators/iterators.o
> kernel/bpf/preload/../../../tools/lib/bpf/bpf.o
> 
> see three pairs above. the first pair comes from $(srctree) somehow.
> 
>>    userccflags += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi -I $(LIBBPF) \
>>           -I $(srctree)/tools/lib/ \
>>           -I $(srctree)/kernel/bpf/preload/iterators/ -Wno-int-conversion \
>>
>> With that, I'm now getting the following error:
>>
>> root@...k:~/bpf-next# make -j8
>>     DESCEND  objtool
>>     DESCEND  bpf/resolve_btfids
>>     CALL    scripts/atomic/check-atomics.sh
>>     CALL    scripts/checksyscalls.sh
>>     CHK     include/generated/compile.h
>>     CC      kernel/events/core.o
>>     CC [U]  kernel/bpf/preload/iterators/iterators.o
>> kernel/bpf/preload/iterators/iterators.c: In function ‘main’:
>> kernel/bpf/preload/iterators/iterators.c:50:2: warning: ignoring return value of ‘dup’, declared with attribute warn_unused_result [-Wunused-result]
>>     dup(debug_fd);
>>     ^~~~~~~~~~~~~
>> kernel/bpf/preload/iterators/iterators.c:53:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
>>     read(from_kernel, &magic, sizeof(magic));
>>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> kernel/bpf/preload/iterators/iterators.c:85:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
>>     read(from_kernel, &magic, sizeof(magic));
>>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>     CC      kernel/events/ring_buffer.o
>>     CC [U]  kernel/bpf/preload/./../../../tools/lib/bpf/bpf.o
>>     CC [U]  kernel/bpf/preload/./../../../tools/lib/bpf/libbpf.o
>> In file included from kernel/bpf/preload/./../../../tools/lib/bpf/libbpf.c:47:0:
>> ./tools/include/tools/libc_compat.h:11:21: error: static declaration of ‘reallocarray’ follows non-static declaration
>>    static inline void *reallocarray(void *ptr, size_t nmemb, size_t size)
>>                        ^~~~~~~~~~~~
> 
> I saw this in the past when makefile was wrong. I suspect it's related
> to the above issue.
> Could you send me your build script / command line and make version?

Config attached.

   root@...k:~/bpf-next# make --version
   GNU Make 4.1

I always build manually, so plain in src tree build with just make -jX.

Thanks,
Daniel

View attachment "config" of type "text/plain" (244772 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ