summaryrefslogtreecommitdiff
path: root/src/core/bpf
Commit message (Collapse)AuthorAgeFilesLines
* tree-wide: Use correct SPDX license identifierJan Janssen2023-02-241-1/+1
|
* bpf: fix restrict_fs on s390xIlya Leoshkevich2023-01-311-3/+7
| | | | | | | | | | | | | Linux kernel's bpf-next contains BPF LSM support for s390x. systemd's test-bpf-lsm currently fails with this kernel. This is an endianness issue: in the restrict_fs bpf program, magic_number has type unsigned long (64 bits on s390x), but magic_map keys are uint32_t (32 bits). Accessing magic_map using 64-bit keys may work by accident on little-endian systems, but fails hard on big-endian ones. Fix by casting magic_number to uint32_t.
* bpf: disable -fstack-protector in mesonSam James2023-01-191-0/+2
| | | | | | | | | | | In Gentoo, we recently started making Clang behave the same way as our GCC, with -fstack-protector and some friends enabled by default. SSP doesn't make sense for BPF, so disable it explicitly. See also e.g. https://www.spinics.net/lists/netdev/msg556400.html. Bug: https://bugs.gentoo.org/890004
* libbpf: Remove use of deprecated APIsDaan De Meyer2022-10-062-2/+2
|
* Revert "bpf: fix is_allow_list section"James Hilliard2022-10-011-1/+1
| | | | | | | | | | GCC was modified to use the same default section as LLVM, as such this is no longer required. Details: https://github.com/gcc-mirror/gcc/commit/a0aafbc324aa90421f0ce99c6f5bbf64ed163da6 This reverts commit e8b1e9cf1095f9d6d0f1e2dce2503e25fec2e6c5.
* bpf: fix is_allow_list sectionJames Hilliard2022-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The llvm bpf compiler appears to place const volatile variables in a non-standard section which creates an incompatibility with the gcc bpf compiler. To fix this force GCC to also use the rodata section. Note this does emit an assembler warning: Generating src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.unstripped.o with a custom command /tmp/ccM2b7jP.s: Assembler messages: /tmp/ccM2b7jP.s:87: Warning: setting incorrect section attributes for .rodata See: https://github.com/llvm/llvm-project/issues/56468 Fixes: ../src/core/restrict-ifaces.c:45:14: error: ‘struct restrict_ifaces_bpf’ has no member named ‘rodata’; did you mean ‘data’? 45 | obj->rodata->is_allow_list = is_allow_list; | ^~~~~~ | data
* bpf: set gcc std and compile flagsJames Hilliard2022-08-011-0/+3
| | | | This should make gcc bpf compilation more reliable.
* meson: add experimental bpf-gcc compiler supportJames Hilliard2022-06-101-11/+32
| | | | | Not fully working but should make it easier to clean up remaining issues.
* bpf: use __always_inline macro in restrict-ifaces.bpf.cJames Hilliard2022-06-091-1/+1
| | | | This appears to be more reliable at inlining with some compilers.
* meson: always get libbpf include directory from pkgconfigYu Watanabe2022-05-161-5/+1
|
* tree-wide: move `unsigned` to the start of type declarationFrantisek Sumsal2022-02-101-1/+1
| | | | | | | | | | | | | | | | | Even though ISO C11 doesn't mandate in which order the type specifiers should appear, having `unsigned` at the beginning of each type declaration feels more natural and, more importantly, it unbreaks Coccinelle, which has a hard time parsing `long unsigned` and others: ``` init_defs_builtins: /usr/lib64/coccinelle/standard.h init_defs: /home/mrc0mmand/repos/systemd/coccinelle/macros.h HANDLING: src/shared/mount-util.c : 1: strange type1, maybe because of weird order: long unsigned ``` Most of the codebase already "complies", so let's fix the remaining "offenders".
* meson: use full argument names for bpftool gen commandsJames Hilliard2022-02-011-4/+4
| | | | This should be a purely cosmetic change.
* meson: use bpftool based strip when availableJames Hilliard2022-01-311-7/+17
| | | | | This should be useable in bpftool v5.13 or newer based on: https://github.com/torvalds/linux/commit/d80b2fcbe0a023619e0fc73112f2a02c2662f6ab
* meson: generate better arch defines for clang bpf compilationZbigniew Jędrzejewski-Szmek2022-01-041-2/+20
| | | | | | | | | | | | | | The code assume that meson's cpu_family can be mapped directly to '-D__<cpu_family>__'. This works in a surprising number of cases, but not for a few architectures. PPC uses "powerpc", and RISC-V omits the trailing underscores. ARM and RISC-V require a second define too. Fixes #21900. (I don't think this matters too much: we need *something* so that gnu/stubs.h can be successfully included. But we don't actually call syscalls or depend too much on the host environment, so things should be fine as long as we don't get a compilation error.)
* meson: use subdir_done() to reduce indentYu Watanabe2021-12-104-110/+118
|
* bpf: refactor skeleton generationJames Hilliard2021-12-077-23/+150
| | | | This should hopefully fix cross compilation for the bpf programs.
* bpf: fix SPDX short identifier for LGPL-2.1-or-laterZbigniew Jędrzejewski-Szmek2021-10-181-1/+1
|
* bpf: add restrict_fs BPF programIago López Galeiras2021-10-062-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | It hooks into the file_open LSM hook and allows only when the filesystem where the open will take place is present in a BPF map for a particular cgroup. The BPF map used is a hash of maps with the following structure: cgroupID -> (s_magic -> uint32) The inner map is effectively a set. The entry at key 0 in the inner map encodes whether the program behaves as an allow list or a deny list: if its value is 0 it is a deny list, otherwise it is an allow list. When the cgroupID is present in the map, the program checks the inner map for the magic number of the filesystem associated with the file that's being opened. When the program behaves as an allow list, if that magic number is present it allows the open to succeed, when the program behaves as a deny list, it only allows access if the that magic number is NOT present. When access is denied the program returns -EPERM. The BPF program uses CO-RE (Compile-Once Run-Everywhere) to access internal kernel structures without needing kernel headers present at runtime.
* tree-wide: fix SPDX short identifier for LGPL-2.1-or-laterLuca Boccassi2021-10-012-2/+2
| | | | | https://spdx.dev/ids/#:~:text=Allowing%20later%20versions%20of%20a%20license https://spdx.org/licenses/LGPL-2.1-or-later.html
* core: add RestrictNetworkInterfaces= BPF program source codeMauricio Vásquez2021-08-182-0/+66
| | | | | | | | | | | The code is composed by two BPF_PROG_TYPE_CGROUP_SKB programs that are loaded in the cgroup inet ingress and egress hooks (BPF_CGROUP_INET_{INGRESS|EGRESS}). The decision to let a packet pass or not is based on a map that contains the indexes of the interfaces. Signed-off-by: Mauricio Vásquez <mauricio@kinvolk.io>
* bpf: add ip proto matching to socket-bind progJulia Kartseva2021-06-292-14/+26
| | | | | | | | | | Lookup ip protocol in a socket address to allow or deny binding a socket to the address. Matching rule is extended with 'protocol' field. If its value is 0 (IPPROTO_IP) ip protocol comparison is omitted and matching is passed to the next token which is ip ports. Documentation is updated.
* tree-wide: fix typoYu Watanabe2021-05-041-1/+1
|
* meson, bpf: add build rule for socket-bind programJulia Kartseva2021-04-261-0/+14
|
* bpf: add socket-bind BPF program code sourcesJulia Kartseva2021-04-262-0/+150
Introduce BPF program compiled from BPF source code in restricted C - socket-bind. It addresses feature request [0]. The goal is to allow systemd services to bind(2) only to a predefined set of ports. This prevents assigning socket address with unallowed port to a socket and creating servers listening on that port. This compliments firewalling feature presenting in systemd: whereas cgroup/{egress|ingress} hooks act on packets, this doesn't protect from untrusted service or payload hijacking an important port. While ports in 0-1023 range are restricted to root only, 1024-65535 range is not protected by any mean. Performance is another aspect of socket_bind feature since per-packet cost can be eliminated for some port-based filtering policies. The feature is implemented with cgroup/bind{4|6} hooks [1]. In contrast to the present systemd approach using raw bpf instructions, this program is compiled from sources. Stretch goal is to make bpf ecosystem in systemd more friendly for developer and to clear path for more BPF programs. [0] https://github.com/systemd/systemd/pull/13496#issuecomment-570573085 [1] https://www.spinics.net/lists/netdev/msg489054.html