Commit Graph

6 Commits

Author SHA1 Message Date
Viktor Malik 74bb3d47b9
bpf: Replace all non-returning strlcpy with strscpy
JIRA: https://issues.redhat.com/browse/RHEL-9957

commit ffadc372529e268b54c5b98f56da07d8024fa1cb
Author: Azeem Shaikh <azeemshaikh38@gmail.com>
Date:   Tue May 30 15:56:59 2023 +0000

    bpf: Replace all non-returning strlcpy with strscpy
    
    strlcpy() reads the entire source buffer first. This read may exceed the
    destination size limit. This is both inefficient and can lead to linear
    read overflows if a source string is not NUL-terminated [1]. This is not
    the case here, however, in an effort to remove strlcpy() completely [2],
    lets replace strlcpy() here with strscpy(). No return values were used,
    so a direct replacement is safe.
    
      [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
      [2] https://github.com/KSPP/linux/issues/89
    
    Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/bpf/20230530155659.309657-1-azeemshaikh38@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2023-10-26 17:06:16 +02:00
Viktor Malik a0aadd9be9 bpf: iterators: Split iterators.lskel.h into little- and big- endian versions
Bugzilla: https://bugzilla.redhat.com/2178930

commit 0f0e5f5bd5066c9ffaa006e26fc7d092b04d4088
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Sat Jan 28 01:06:43 2023 +0100

    bpf: iterators: Split iterators.lskel.h into little- and big- endian versions
    
    iterators.lskel.h is little-endian, therefore bpf iterator is currently
    broken on big-endian systems. Introduce a big-endian version and add
    instructions regarding its generation. Unfortunately bpftool's
    cross-endianness capabilities are limited to BTF right now, so the
    procedure requires access to a big-endian machine or a configured
    emulator.
    
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230128000650.1516334-25-iii@linux.ibm.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2023-06-13 22:45:02 +02:00
Jerome Marchand d63af8a374 bpf: Fix issue with bpf preload module taking over stdout/stdin of kernel.
Bugzilla: https://bugzilla.redhat.com/2120966

commit 80bebebdac935473568c27d4f1349dc8f9809bf7
Author: Yucong Sun <fallentree@fb.com>
Date:   Fri Feb 25 10:59:24 2022 -0800

    bpf: Fix issue with bpf preload module taking over stdout/stdin of kernel.

    In cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.")
    BPF preload was switched from user mode process to use in-kernel light
    skeleton instead. However, in the kernel context, early in the boot
    sequence, the first available FD can start from 0, instead of normally
    3 for user mode process. So FDs 0 and 1 are then used for loaded BPF
    programs and prevent init process from setting up stdin/stdout/stderr on
    FD 0, 1, and 2 as expected.

    Before the fix:

    ls -lah /proc/1/fd/*

    lrwx------1 root root 64 Feb 23 17:20 /proc/1/fd/0 -> /dev/null
    lrwx------ 1 root root 64 Feb 23 17:20 /proc/1/fd/1 -> /dev/null
    lrwx------ 1 root root 64 Feb 23 17:20 /proc/1/fd/2 -> /dev/console
    lrwx------ 1 root root 64 Feb 23 17:20 /proc/1/fd/6 -> /dev/console
    lrwx------ 1 root root 64 Feb 23 17:20 /proc/1/fd/7 -> /dev/console

    After the fix:

    ls -lah /proc/1/fd/*

    lrwx------ 1 root root 64 Feb 24 21:23 /proc/1/fd/0 -> /dev/console
    lrwx------ 1 root root 64 Feb 24 21:23 /proc/1/fd/1 -> /dev/console
    lrwx------ 1 root root 64 Feb 24 21:23 /proc/1/fd/2 -> /dev/console

    Fix by closing prog FDs after initialization. struct bpf_prog's
    themselves are kept alive through direct kernel references taken with
    bpf_link_get_from_fd().

    Fixes: cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.")
    Signed-off-by: Yucong Sun <fallentree@fb.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20220225185923.2535519-1-fallentree@fb.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2022-10-25 14:57:51 +02:00
Jerome Marchand e8ea7c6063 bpf: Convert bpf_preload.ko to use light skeleton.
Bugzilla: https://bugzilla.redhat.com/2120966

commit cb80ddc67152e72f28ff6ea8517acdf875d7381d
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Wed Feb 9 15:20:01 2022 -0800

    bpf: Convert bpf_preload.ko to use light skeleton.

    The main change is a move of the single line
      #include "iterators.lskel.h"
    from iterators/iterators.c to bpf_preload_kern.c.
    Which means that generated light skeleton can be used from user space or
    user mode driver like iterators.c or from the kernel module or the kernel itself.
    The direct use of light skeleton from the kernel module simplifies the code,
    since UMD is no longer necessary. The libbpf.a required user space and UMD. The
    CO-RE in the kernel and generated "loader bpf program" used by the light
    skeleton are capable to perform complex loading operations traditionally
    provided by libbpf. In addition UMD approach was launching UMD process
    every time bpffs has to be mounted. With light skeleton in the kernel
    the bpf_preload kernel module loads bpf iterators once and pins them
    multiple times into different bpffs mounts.

    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20220209232001.27490-6-alexei.starovoitov@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2022-10-25 14:57:49 +02:00
Zqiang f60a85cad6 bpf: Fix umd memory leak in copy_process()
The syzbot reported a memleak as follows:

BUG: memory leak
unreferenced object 0xffff888101b41d00 (size 120):
  comm "kworker/u4:0", pid 8, jiffies 4294944270 (age 12.780s)
  backtrace:
    [<ffffffff8125dc56>] alloc_pid+0x66/0x560
    [<ffffffff81226405>] copy_process+0x1465/0x25e0
    [<ffffffff81227943>] kernel_clone+0xf3/0x670
    [<ffffffff812281a1>] kernel_thread+0x61/0x80
    [<ffffffff81253464>] call_usermodehelper_exec_work
    [<ffffffff81253464>] call_usermodehelper_exec_work+0xc4/0x120
    [<ffffffff812591c9>] process_one_work+0x2c9/0x600
    [<ffffffff81259ab9>] worker_thread+0x59/0x5d0
    [<ffffffff812611c8>] kthread+0x178/0x1b0
    [<ffffffff8100227f>] ret_from_fork+0x1f/0x30

unreferenced object 0xffff888110ef5c00 (size 232):
  comm "kworker/u4:0", pid 8414, jiffies 4294944270 (age 12.780s)
  backtrace:
    [<ffffffff8154a0cf>] kmem_cache_zalloc
    [<ffffffff8154a0cf>] __alloc_file+0x1f/0xf0
    [<ffffffff8154a809>] alloc_empty_file+0x69/0x120
    [<ffffffff8154a8f3>] alloc_file+0x33/0x1b0
    [<ffffffff8154ab22>] alloc_file_pseudo+0xb2/0x140
    [<ffffffff81559218>] create_pipe_files+0x138/0x2e0
    [<ffffffff8126c793>] umd_setup+0x33/0x220
    [<ffffffff81253574>] call_usermodehelper_exec_async+0xb4/0x1b0
    [<ffffffff8100227f>] ret_from_fork+0x1f/0x30

After the UMD process exits, the pipe_to_umh/pipe_from_umh and
tgid need to be released.

Fixes: d71fa5c976 ("bpf: Add kernel module with user mode driver that populates bpffs.")
Reported-by: syzbot+44908bb56d2bfe56b28e@syzkaller.appspotmail.com
Signed-off-by: Zqiang <qiang.zhang@windriver.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20210317030915.2865-1-qiang.zhang@windriver.com
2021-03-19 22:23:19 +01:00
Alexei Starovoitov d71fa5c976 bpf: Add kernel module with user mode driver that populates bpffs.
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@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200819042759.51280-4-alexei.starovoitov@gmail.com
2020-08-20 16:02:36 +02:00