Frantisek Sumsal [Mon, 31 Jan 2022 13:19:09 +0000 (14:19 +0100)]
test: copy portable profiles into the image if they don't exist there
If we're built with `-Dportable=false`, the portable profiles won't get
installed into the image. Since we need only the profile files and
nothing else, let's copy them into the image explicitly in such case.
Frantisek Sumsal [Mon, 31 Jan 2022 16:11:06 +0000 (17:11 +0100)]
test: use ~/.bashrc instead of /etc/bash.bashrc
/etc/bash.bashrc appears to be Debian-specific[0] (or specific to bash
versions compiled with -DSYS_BASHRC), which doesn't seem to be the case
for C8S. Let's use ~/.bashrc instead to make the CIs happy again.
Luca Boccassi [Fri, 28 Jan 2022 22:56:10 +0000 (22:56 +0000)]
core: don't fail on EEXIST when creating mount point
systemd[1016]: Failed to mount /tmp/app1 (type n/a) on /run/systemd/unit-extensions/1 (MS_BIND ): No such file or directory
systemd[1016]: Failed to create destination mount point node '/run/systemd/unit-extensions/1': File exists
James Hilliard [Mon, 31 Jan 2022 02:33:55 +0000 (19:33 -0700)]
meson: set minimum clang/llvm versions for bpf support
The minimum clang/llvm-strip version needed for building libbpf based
programs is 10.0.0, this is documented here:
https://github.com/libbpf/libbpf/tree/v0.6.1#bpf-co-re-compile-once--run-everywhere
Using an older version such as 9.0.0 will generate objects that
bpftool will not be able to generate skeletons for.
This fixes the following build fail on current Fedora Rawhide:
```
../src/basic/meson.build:389:8: ERROR: Problem encountered: found unknown filesystem(s) defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: CIFS_SUPER_MAGIC
Filesystem found in kernel header but not in filesystems-gperf.gperf: SMB2_SUPER_MAGIC
```
Davide Cavalca [Sun, 30 Jan 2022 17:28:52 +0000 (09:28 -0800)]
hwdb: add new database file for PDA devices
Add a new database for handhelds (PDAs, calculators, etc.) that should be
accessible the seat owner.
The database is initially populated with Texas Instruments calculators
and linking cables, which removes the need to installing dedicated udev
rules for them.
Donald Chan [Fri, 28 Jan 2022 22:53:46 +0000 (22:53 +0000)]
basic: mac_[selinux,smack]_apply_fd does not work when applying labels
Commit a7fdc6c introduced a regression where file descriptors are opened
using O_PATH option. mac_smack_apply_fd() calls fsetxattr() and would fail
with a -EBADF (Bad file descriptor) error.
Use FORMAT_PROC_FD_PATH(fd) to convert the fd back into a full path and
call setxattr() or setfilecon() instead.
The idea behind this action is to make it possible to compare the
latest fuzz targets with PRs to figure out whether bugs are really
reproducible in PRs only. Since forks (including systemd-stable) are
usually based on the upstream repository where almost all the bugs
are fixed before releases are cut it should be safe to assume that
if CFLite finds bugs in PRs they are most likely introduced in those
PRs.
It should probably be brought back once https://github.com/google/clusterfuzzlite/issues/84
is fixed.
ci: use CFLite to test forks (including systemd-stable)
It's like CIFuzz but unlike CIFuzz it's compatible with forks and
it should make it possible to run the fuzzers to make sure that
patches backported to them are backported correctly without introducing
new bugs and regressions.
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
#0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
#1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
#2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
#3 0x7fdf4f8b474f (/lib64/libc.so.6+0x4274f)
#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)
The general approach of kernel-install was that each plugin would drop in some
files into the entry directory. But this doesn't scale well, because if we have
multiple initrd generators, or multiple initrds, each generator would need to
recreate the logic to put the generated files in the right place.
Also, effective cleanup is impossible if anything goes wrong on the way, so we
could end up with unused files in $BOOT.
So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA,
and at the end 90-loaderentry.install DTRT with those files.
This allow new plugins like 50-mkosi-initrd.install to be significantly simpler.
kernel-install: prefix errors with "Error:", exit immediately
kernel-install would continue after errors… We don't want this, as it
makes the results totally unpredicatable. If we didn't install the kernel
or didn't do some important part of the setup, let's just return an error
and let the user deal with it.
When looking at output, the error was often hard to distinguish, esp.
with -v. Add "Error:" everywhere to make the output easier to parse.
Julia Kartseva [Fri, 28 Jan 2022 00:36:25 +0000 (16:36 -0800)]
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.
Luca Boccassi [Thu, 27 Jan 2022 14:10:34 +0000 (14:10 +0000)]
core: do not attempt to add 'private' symlinks when RootImage/RootDirectory are used
A bind mount is added directly from private on the host to the actual
destination directory, no need for the symlinks (which cannot be created
as the bind mount happens first and creates the target as an actual directory)
Yu Watanabe [Fri, 28 Jan 2022 00:29:59 +0000 (09:29 +0900)]
resolve: llmnr: fix never hit condition
Previously, the condition in on_stream_io_impl() never hit, as the
read packet is always taken from the stream in the few lines above.
Instead of the dns_stream_complete() under the condition, the stream
is unref()ed in the on_packet callback for LLMNR stream, unlike the
other on_packet callbacks.
That's quite tricky. Also, potentially, the stream may still have
queued packets to write.
This fix the condition, and drops the unref() in the on_packet callback.
Yu Watanabe [Thu, 27 Jan 2022 22:29:32 +0000 (07:29 +0900)]
test-network: wait for a while if manual policy is always-{up,down}
If wait_operstate() is called super quickly after ip command, then the
up/down state may not be changed and propagated to networkd, and
wait_operstate() mistakenly pass with the previous state.
To avoid such situation, wait for a while to make networkd actually
detect the interface brought up/down.
Yu Watanabe [Thu, 27 Jan 2022 22:02:00 +0000 (07:02 +0900)]
test-network: wait for the link is activated
This fixes the following race:
1. when a dummy interface is created, it is initially down state,
2. hence, wait_operstate() may pass before the link is activated,
3. and the ip command bring up the interface before the activation,
4. and networkd activates, that is, brings down the interface,
5. thus, next wait_operstate() timedout, as it waits for the interface up.
To fix the race, let's wait the link is activated, before enter the loop
of wait_operstate().
Frantisek Sumsal [Thu, 27 Jan 2022 21:51:15 +0000 (22:51 +0100)]
test: temporary workaround for #21819
Since the TEST-64-UDEV-STORAGE fails are quite frequent now and the root
cause is yet to be discovered, let's add a kludge that attempts to retry
the test up to two more times in case it fails, so we don't
unnecessarily disturb CIs while the issue is being investigated.
Joan Bruguera [Sun, 23 Jan 2022 16:08:12 +0000 (17:08 +0100)]
resolved: Test for DnsStream (plain TCP DNS and DoT)
Tests DnsStream event handling, both for plain TCP DNS and DNS over TLS.
The DoT test requires the "openssl s_server" command line tool to mock a simple
TLS server. Thus the test's TLS part is skipped if openssl it not available.
The test works for both DNS_OVER_TLS_USE_GNUTLS and DNS_OVER_TLS_USE_OPENSSL.
The DoT case fails due to a bug, which is fixed on the next commit.
Joan Bruguera [Sat, 15 Jan 2022 16:33:25 +0000 (17:33 +0100)]
resolved: Fix DoT timeout on multiple answer records
When sending multiple DNS questions to a DNS-over-TLS server (e.g. a question
for A and AAAA records, as is typical) on the same session, the server may
answer to each question in a separate TLS record, but it may also aggregate
multiple answers in a single TLS record.
(Some servers do this very often (e.g. Cloudflare 1.0.0.1), some do it sometimes
(e.g. Google 8.8.8.8) and some seem to never do it (e.g. Quad9 9.9.9.10)).
Both cases should be handled equivalently, as the byte stream is the same, but
when multiple answers came in a single TLS record, usually the first answer was
processed, but the second answer was entirely ignored, which caused a 10s delay
until the resolution timed out and the missing question was retried.
This can be reproduced by configuring one of the offending server and running
`resolvectl query google.com --cache=no` a few times.
To be notified of incoming data, systemd-resolved listens to `EPOLLIN` events
on the underlying socket. However, when DNS-over-TLS is used, the TLS library
(OpenSSL or GnuTLS) may read and buffer the entire TLS record when reading the
first answer, so usually no further `EPOLLIN` events will be generated, and the
second answer will never be processed.
To avoid this, if there's buffered TLS data, generate a "fake" EPOLLIN event.
This is hacky, but it makes this case transparent to the rest of the IO code.
projects / thirdparty / systemd.git / log
