Commit Graph
33 Commits
Author SHA1 Message Date
Lennart Poettering 3a51cf673f bpf-devices: if a device node is referenced which doesn't exist, downgrade log message
Currently in many of our test cases you'll see a warning about a tun
device not being around. Let's make that quiet, since if there's no such
device there's no point in adding it to a policy anyway, and it makes
useless noise go away.

We keep the warning as a warning if a device node is missing for other
errors than ENOENT.
2024-02-09 15:32:10 +01:00
Lennart Poettering 958b73bef1 bpf-devices: normalize the return handling of functions that put together policy
under some conditions we suppress generating BPF programs. Let's
systematically return 0 when we do this, and 1 if we did actually
soething, instead of second guessing this in the caller.

This is not only more correct, but allows us to suppress BPF programs in
more cases in later commits.
2024-02-09 15:32:10 +01:00
Lennart Poettering 893220f62f bpf-devices: normalize how we pass around major/minor values
There's some unclarity whether major/minor of device nodes are supposed
to be "unsigned" or "dev_t". Various codebases assume the latter, but
glibc's major()/minor() types actually return a value typed to
"unsigned". On glibc dev_t is actually 64bit even if the kernel only
exposes 32bit. Hence this distinction kinda matters.

Let's clean things up a bit with handling: let's followe glibc's type
system here, and use unsigned (and not int).

Also let's pass invalid major/minor values around as UINT_MAX rather
than via pointers, to match how we usually do this, and to shorten our
code a bit. This is safe, since given the linux dev_t space being 32bit
only we can't possibly have a valid major or minor this hight, given
they must be smaller in size. While other archs disagree on the types of
major/minor, they also tend to have similar limits. In fact on FreeBSD
for example major()/minor() returns a signed int. Which would hence also
mean that UINT_MAX cannot be a valid major or minor.
2024-02-09 15:32:04 +01:00
Lennart Poettering a104481144 cgroup: turn device cgroup controller "rwm" strings into proper flags
We generally prefer dealing with parsed data instead of original
strings, do so for the "rwm" strings too. We have to convert this to
flags for the primary backend implementation (BPF) anyway, hence we
can do this early to have simpler, shorter and more normalized code.
2023-10-17 23:27:01 +01:00
Daan De Meyer 12e2b70f9b nulstr-util: Declare NULSTR_FOREACH() iterator inline 2022-11-11 16:31:32 +01:00
Lennart Poettering 7176f06c9e basic: split out dev_t related calls into new devno-util.[ch]
No actual code changes, just splitting out of some dev_t handling
related calls from stat-util.[ch], they are quite a number already, and
deserve their own module now I think.

Also, try to settle on the name "devnum" as the name for the concept,
instead of "devno" or "dev" or "devid". "devnum" is the name exported in
udev APIs, hence probably best to stick to that. (this just renames a
few symbols to "devum", local variables are left untouched, to make the
patch not too invasive)

No actual code changes.
2022-04-13 16:26:31 +02:00
Yu Watanabe 798931160e tree-wide: add a space after if, switch, for, and while 2022-04-01 22:48:42 +09:00
Julia Kartseva e0c694c73d bpf: load firewall with name only if supported
BPF firewall is supported starting from v4.9 kernel where
BPF_PROG_TYPE_SOCKET_FILTER support was added [0].

However, program name support was added to v4.15 [1] and BPF_PROG_LOAD
syscall will fail on older kernels if called with prog_name attribute.
BPF_F_ALLOW_MULTI was also added to v4.15 kernel which allows reusing
BPF_F_ALLOW_MULTI probe to indicate that program name is also supported.

It is no problem for BPF_PROG_TYPE_CGROUP_DEVICE since it was added in
v4.15.

[0] https://elixir.bootlin.com/linux/v4.9/source/include/uapi/linux/bpf.h#L92
[1] https://elixir.bootlin.com/linux/v4.15/source/include/uapi/linux/bpf.h#L191

Follow-up of https://github.com/systemd/systemd/pull/22214
2022-01-28 12:42:18 +09:00
Julia Kartseva 8fe9dbb926 bpf: name unnamed bpf programs
bpf-firewall and bpf-devices do not have names. This complicates
debugging with bpftool(8).

Assign names starting with 'sd_' prefix:
* firewall program names are 'sd_fw_ingress' for ingress attach
point and 'sd_fw_egress' for egress.
* 'sd_devices' for devices prog

'sd_' prefix is already used in source-compiled programs, e.g.
sd_restrictif_i, sd_restrictif_e, sd_bind6.

The name must not be longer than 15 characters or BPF_OBJ_NAME_LEN - 1.

Assign names only to programs loaded to kernel by systemd since
programs pinned to bpffs are already loaded.
2022-01-22 16:48:42 +09:00
alexlzhu 76dc17254f core: remove refcount for bpf program
Currently ref count of bpf-program is kept in user space. However, the
kernel already implements its own ref count. Thus the ref count we keep for
bpf-program is redundant.

This PR removes ref count for bpf program as part of a task to simplify
bpf-program and remove redundancies, which will make the switch to
code-compiled BPF programs easier.

Part of #19270
2021-10-12 12:48:23 +02:00
Yu Watanabe 6178e2f889 core: wrap cgroup path with empty_to_root() in log messages
This fixes e.g. the following log message:
---
systemd[1]: -.slice: Failed to migrate controller cgroups from , ignoring: Read-only file system
---
2021-08-05 03:14:46 +09:00
Zbigniew Jędrzejewski-Szmek 5600a26114 bpf-devices: update comment 2021-04-14 15:29:41 +02:00
Yu Watanabe db9ecf0501 license: LGPL-2.1+ -> LGPL-2.1-or-later 2020-11-09 13:23:58 +09:00
Lennart Poettering 6b000af4f2 tree-wide: avoid some loaded terms
https://tools.ietf.org/html/draft-knodel-terminology-02
https://lwn.net/Articles/823224/

This gets rid of most but not occasions of these loaded terms:

1. scsi_id and friends are something that is supposed to be removed from
   our tree (see #7594)

2. The test suite defines an API used by the ubuntu CI. We can remove
   this too later, but this needs to be done in sync with the ubuntu CI.

3. In some cases the terms are part of APIs we call or where we expose
   concepts the kernel names the way it names them. (In particular all
   remaining uses of the word "slave" in our codebase are like this,
   it's used by the POSIX PTY layer, by the network subsystem, the mount
   API and the block device subsystem). Getting rid of the term in these
   contexts would mean doing some major fixes of the kernel ABI first.

Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
2020-06-25 09:00:19 +02:00
Lennart Poettering 07141aa005 bpf-devices: line-break some overly long function signatures 2020-01-07 18:41:36 +01:00
Zbigniew Jędrzejewski-Szmek 45669ae264 bpf: make sure the kernel do not submit an invalid program if no pattern matched
It turns out that the kernel verifier would reject a program we would build
if there was a whitelist, but no entries in the whitelist matched.
The program would approximately like this:
   0: (61) r2 = *(u32 *)(r1 +0)
   1: (54) w2 &= 65535
   2: (61) r3 = *(u32 *)(r1 +0)
   3: (74) w3 >>= 16
   4: (61) r4 = *(u32 *)(r1 +4)
   5: (61) r5 = *(u32 *)(r1 +8)
  48: (b7) r0 = 0
  49: (05) goto pc+1
  50: (b7) r0 = 1
  51: (95) exit
and insn 50 is unreachable, which is illegal. We would then either keep a
previous version of the program or allow everything. Make sure we build a
valid program that simply rejects everything.
2019-11-11 15:14:09 +01:00
Zbigniew Jędrzejewski-Szmek 0048657828 bpf: optimize device type access away most of the time
Most of the time, we specify the allowed access mode as "rwm", so the check
always trivially passes. In that case, skip the check.

The repeating part changes from:
   5: (55) if r2 != 0x2 goto pc+6
   6: (bc) w1 = w3
   7: (54) w1 &= 7
   8: (5d) if r1 != r3 goto pc+3
   9: (55) if r4 != 0x1 goto pc+2
  10: (55) if r5 != 0x3 goto pc+1
  11: (05) goto pc+8
to
   6: (55) if r2 != 0x2 goto pc+3
   7: (55) if r4 != 0x1 goto pc+2
   8: (55) if r5 != 0x3 goto pc+1
   9: (05) goto pc+40
2019-11-11 15:14:02 +01:00
Zbigniew Jędrzejewski-Szmek 8ad08622d6 bpf: convert 'c'/'b' to bpf_type at the very end
This makes the code a bit longer, but easier to read I think, because
the cgroup v1 and v2 code paths are more similar. And whent he type is
a char, any backtrace is easier to interpret.
2019-11-11 15:13:56 +01:00
Zbigniew Jędrzejewski-Szmek 7973f56468 test-bpf-devices: new test for the devices bpf code 2019-11-11 15:13:38 +01:00
Zbigniew Jędrzejewski-Szmek a72a5326a4 bpf: fix off-by-one in class whitelisting
We would jump one insn too many, landing in the middle of the subsequent block.
2019-11-11 14:55:57 +01:00
Zbigniew Jędrzejewski-Szmek 415fe5ec7d bpf: fix device type filter
On big endian arches, we were taking the wrong half-word, so the check
was giving bogus results.

https://bugzilla.redhat.com/show_bug.cgi?id=1769148.
2019-11-11 14:55:57 +01:00
Zbigniew Jędrzejewski-Szmek 786cce0099 bpf: add trace logging
Very helpful when trying to figure out what exactly is going on.
2019-11-11 14:55:57 +01:00
Zbigniew Jędrzejewski-Szmek 0848715cab bpf: make bpf_devices_apply_policy() independent of any unit code 2019-11-11 14:55:57 +01:00
Zbigniew Jędrzejewski-Szmek a9aac7d8dd core: also split out helper to handle static device nodes 2019-11-10 23:22:15 +01:00
Zbigniew Jędrzejewski-Szmek 124e05b3b6 core: move bpf devices implementation to bpf-devices.[ch] and rename
The naming of the functions was a complete mess: the most specific functions
which don't know anything about cgroups had "cgroup_" prefix, while more
general functions which took a node path and a cgroup for reporting had no
prefix. Let's use "bpf_devices_" for the latter group, and "bpf_prog_*" for the
rest.

The main goal of this move is to split the implementation from the calling code
and add unit tests in a later patch.
2019-11-10 23:22:15 +01:00
Zbigniew Jędrzejewski-Szmek 084870f9c0 core: rename CGROUP_AUTO/STRICT/CLOSED to CGROUP_DEVICE_POLICY_…
The old names were very generic, and when used without context it wasn't at all
clear that they are about the devices policy.
2019-11-10 23:22:15 +01:00
Zbigniew Jędrzejewski-Szmek 2899aac46a core: constify bpf program arrays
In cases where the programs were modified after being initially declared,
reorder operations so that the declaration is already in final form.
2019-11-10 23:22:14 +01:00
Yu Watanabe 01234e1fe7 tree-wide: drop several missing_*.h and import relevant headers from kernel-5.0 2019-04-11 19:00:37 +02:00
Topi Miettinen 7ae3561a5a Delete duplicate lines
Found by inspecting results of running this small program:

int main(int argc, const char **argv) {
	for (int i = 1; i < argc; i++) {
		FILE *f;
		char line[1024], prev[1024], *r;
		int lineno;

		prev[0] = '\0';
		lineno = 1;
		f = fopen(argv[i], "r");
		if (!f)
			exit(1);
		do {
			r = fgets(line, sizeof(line), f);
			if (!r)
				break;
			if (strcmp(line, prev) == 0)
				printf("%s:%d: error: dup %s", argv[i], lineno, line);
			lineno++;
			strcpy(prev, line);
		} while (!feof(f));
		fclose(f);
	}
}
2019-01-12 16:02:26 +01:00
Lennart Poettering 8e8b5d2e6d cgroups: beef up DeviceAllow= syntax a bit
Previously we'd allow pattern expressions such as "char-input" to match
all input devices. Internally, this would look up the right major to
test in /proc/devices. With this commit the syntax is slightly extended:

- "char-*" can be used to match any kind of character device, and
  similar "block-*. This expression would work previously already, but
  instead of actually installing a wildcard match it would install many
  individual matches for everything listed in /proc/devices.

- "char-<MAJOR>" with "<MAJOR>" being a numerical parameter works now
  too. This allows clients to install whitelist items by specifying the
  major directly.

The main reason to add these is to provide limited compat support for
clients that for some reason contain whitelists with major/minor numbers
(such as OCI containers).
2018-11-29 20:21:39 +01:00
Pavel Hrdina 2af3eed1aa bpf-devices: fix order of removing and adding BPF programs
The current code has multiple issues and it should never be done like
that.  If someone updates list of allowed devices we should attach new
program before we remove the old one for two reasons:

1. It takes some time to attach new program so there is a period of time
when all devices are allowed.

2. BPF programs have limit for number of instructions (4096) and if user
adds a lot of devices we might hit the instruction limit and the new
program will not be accepted which will result in allow all devices
because the old program was already removed.

In order to attach the new program before we remove the old one we need
to use BPF_F_ALLOW_MULTI flag every time.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2018-11-13 14:03:01 +01:00
Pavel Hrdina 0b82cd2502 bpf-devices: fix cgroup v2 devices detection
If cgroup v2 bpf devices is supported we need to return 1, not -1.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2018-11-13 12:58:05 +01:00
Roman Gushchin 084c700780 core: support cgroup v2 device controller
Cgroup v2 provides the eBPF-based device controller, which isn't currently
supported by systemd. This commit aims to provide such support.

There are no user-visible changes, just the device policy and whitelist
start working if cgroup v2 is used.
2018-10-09 09:47:51 -07:00