Daan De Meyer [Sun, 11 May 2025 07:42:28 +0000 (09:42 +0200)]
meson: Stop doing nested build when fuzzers are enabled
Currently, when fuzzers are enabled, we run meson from within meson
to build the fuzzer executables with sanitizers. The idea is that
we can build the fuzzers with different kinds of sanitizers
independently from the main build.
The issue with this setup is that we don't actually make use of it.
We only build the fuzzers with one set of sanitizers (address,undefined)
so we're adding a bunch of extra complexity without any benefit as we
can just setup the top level meson build with these sanitizers and get
the same result.
The other issue with this setup is that we don't pass on all the options
passed to the top level meson build to the nested meson build. The only things
we pass on are extra compiler arguments and the value of the auto_features
option, but none of the individual feature options if overridden are passed on,
which can lead to very hard to debug issues as an option enabled in the top
level build is not enabled in the nested build.
Since we're not getting anything useful out of this setup, let's simplify
and get rid of the nested meson build. Instead, sanitizers should be enabled
for the top level meson.build. This currently didn't work as we were overriding
the sanitizers passed to the meson build with the fuzzer sanitizer, so we
fix that as well by making sure we combine the fuzzer sanitizer with the ones
passed in by the user.
We also drop support for looking up libFuzzer as a separate library as
it has been shipped builtin in clang since clang 6.0, so we can assume
that -fsanitize=fuzzer is available.
To make sure we still run the fuzzing tests, we enable the fuzz-tests option
by default now to make sure they still always run (without instrumentation unless
one of llvm-fuzz or oss-fuzz is enabled).
bless-boot: never try to rename an entry file onto itself
If we are booting a known bad entry, and we are asked to mark it as bad,
we so far would end up renaming the entry onto itself, which resulted in
EEXIST and is really borked operation. Let's catch that case and handle
it explicitly.
bless-boot: in "status" output report bad state from prev boot as "dirty"
The bless-boot logic currently assumes that if the name of the boot
entry reported via the EFI var matches the name on disk that the state
is "indeterminate", as we haven't counted down the counter (to mark it
bad) or drop the counter (to mark it good) yet. But there's one corner
case we so far didn't care about: what if the entry already reached 0
left tries in a previous boot, i.e. if the user invoked an entry already
known to be completely bad. In that case we'd still return
"indeterminate", but that's kinda misleading, because we *know* the
currently booted entry is bad, however we inherited that fact from a
previous boot, we didn't determine it on the current.
hence, let's introduce a new status we report in this case, that is both
distinct from "bad" (which indicates whether the *current* boot is bad)
and "indirect" (which indicates the current boot has not been decided on
yet): "dirty".
Why "dirty"? To mirror "clean" which we already have, which indicates a
boot already marked good in a previous boot, which is a relatively
symmetric state.
This is a really weak api break of sorts, because it introduces a new
state we never reported before, but I think it's fine, because the old
reporting was just wrong, and in a way this is bugfix, that we now
report correctly something where previously returned kind of rubbish
(though systematic rubbish).
Valentin Hăloiu [Sun, 11 May 2025 00:33:28 +0000 (01:33 +0100)]
Add netdev files associated with link to networkd JSON output (#37402)
`networkctl status LINK` gained support for showing the netdev
configuration files associated with a link in c9837c17d57d7e0fd9d3e2a4f2693f389ca76c24, but these netdev files were
never added to the JSON output too.
This pull-request fixes that by adding two new fields (`NetDevFile` and
`NetDevFileDropins`) to the `networkctl` (and `D-Bus`) JSON output.
Yu Watanabe [Thu, 1 May 2025 11:58:18 +0000 (20:58 +0900)]
core: disable mounting disconnected private tmpfs on /var/tmp/ when DefaultDependencies=no
If DefaultDependencies=no, /var/ may not be mounted yet when the service
is being started. Previously, In such case, if the service has
PrivateTmp=disconnected, the service manager created /var/tmp/ on the
root filesystem and mounted the disconnected private tmpfs there. That
poluted the root filesystem and disturbed gpt-auto-generator on next
boot, as /var/ would not be empty anymore. See issue #37258.
This changes PrivateTmp=disconnected as the following:
- If DefaultDependencies=no and RootDirectory=/RootImage= are not set,
then a private tmpfs is mounted _only_ on /tmp/, and set $TMPDIR=/tmp
environment variable to suggest the service to use /tmp/.
- If DefaultDependencies=yes and RootDirectory=/RootImage= are not set,
then implies RequiresMountsFor=/var/, though that is typically
redundant, but anyway. Hence, we can safely mount /var/tmp/.
- Otherwise, i.e. when one of RootDirectory=/RootImage= is set, behaves
as the same as the previous, as the private root filesystem for the
service is explicitly prepared by the service manager, and we can
safely mount a private tmpfs on /var/tmp/ without any extra
dependencies.
Yu Watanabe [Sat, 10 May 2025 18:22:04 +0000 (03:22 +0900)]
core/mount: drop unnecessary dependency generations
When the unit is new, then mount_setup_new_unit() adds the unit to the
load queue, and the same dependencies will be anyway added.
When the unit already exists but previously failed to be loaded, then
mount_setup_existing_unit() also adds the unit to the load queue.
Hence it is not necessary to regenerate dependencies here now.
So, we need to regenerate dependencies only when things changed and
the unit has been already loaded.
Unfortunately, the kernel may send events in a random order:
```
[ 25.769624] systemd-udevd[194]: sdi7: Device is queued (SEQNUM=2843, ACTION=add)
[ 25.769893] systemd-udevd[194]: sda5: Device is queued (SEQNUM=2842, ACTION=add)
[ 25.770517] systemd-udevd[194]: sdi8: Device is queued (SEQNUM=2844, ACTION=add)
```
As you can see, udevd receives the event with SEQNUM=2843 earlier than
one with SEQNUM=2842.
Let's make queued events sorted, as our logic of determining which event
is ready for being processed assumes that queued events are sorted.
See event_build_dependencies().
Also, refuse to queue an event if another event with the same seqnum is
already queued.
Yu Watanabe [Tue, 6 May 2025 16:09:09 +0000 (01:09 +0900)]
udev: refactoring for managing events for locked block devices
Previously, when an event for block device is queued or an inotify event
for a block device is triggered, all queued events were checked by
event_queue_assume_block_device_unlocked(), and its cost may be huge
on early boot stage.
This makes locked events are managed in separated prioq and hashmap,
to reduce the cost of event_queue_assume_block_device_unlocked(),
which is now renamed to manager_requeue_locked_events_by_device().
This also changes the clockid of timer events for requeueing and
timeout of retry from CLOCK_BOOTTIME to CLOCK_MONOTONIC. Otherwise,
if the system suspend while an event is locked, the event may be
requeued immediately after come back from the suspend and timed out.
Luca Boccassi [Wed, 7 May 2025 23:49:25 +0000 (00:49 +0100)]
boot: skip shim-specific logic when running with new shim
Since shim 16 the plain BS->LoadImage() will just work (TM), we do not need
anymore to set up manual overrides and manually call in the shim-specific
lock protocol or to set shim-specific EFIVAR to make addons work or to load
shim-signed kernels.
Check if the new protocol added in v16 is present, and if so, skip
all that. Once versions < 16 are no longer supported/revoked, all
the code can be dropped entirely.
Note, BPF_PROG_TYPE_CGROUP_DEVICE is supported since kernel v4.15.
As our baseline on the kernel is v5.4, we can assume the bpf type is
always supported.
core/bpf-firewall: replace bpf_firewall_supported() with bpf_program_supported()
Note, BPF_PROG_TYPE_CGROUP_SKB is supported since kernel v4.10, and
BPF_F_ALLOW_MULTI and program name is supported since kernel v4.15.
As our baseline on the kernel is v5.4, we can assume that the type,
flag, and naming is supported when bpf_program_supported() succeeds.
core: replace cgroup_bpf_supported() with dlopen_bpf_full()
After 3988e2489aaf30034e09918890f688780c154af7, the function is a simple
wrapper of bpf_dlopen() with logging. Let's introduce dlopen_bpf_full()
that takes log level, and replace cgroup_bpf_supported() with it.
man: rework the description of $SYSTEMD_PAGER and $PAGER
$PAGER wasn't documented, but actually we treat it same as $SYSTEMD_PAGER,
except for lower priority. And the two variables can be used to disable the
pager, even if $SYSTEMD_PAGERSECURE is not set.
Behaviour is (obviously) not changed by this patch, it intentionally just
updates the docs to match the code.
man: reword the description of "secure pager" handling
The existing description was not *wrong*, but it was a bit muddled. Let's
reorder the text to give a short intro and then describe what the options
actually do and the clear "true" and "false" cases first, and then describe
autodetection.
Related to https://yeswehack.com/vulnerability-center/reports/346802.
Daan De Meyer [Wed, 7 May 2025 09:43:44 +0000 (11:43 +0200)]
compress: Drop lz4 includes from compress.h
The lz4 functions are only used in test-compress.c, so let's just
put the declarations and includes in there instead of having everyone
including compress.h pull in the lz4 headers.
Daan De Meyer [Tue, 6 May 2025 13:39:03 +0000 (15:39 +0200)]
basic: Override glibc's sys/param.h header with an empty file
Instead of unconditionally including sys/param.h in
macro-fundamental.h which itself includes a bunch of other unnecessary
headers, let's override it with an empty file to avoid it from overriding
our MAX() macro. We can't make including it an error as it's included (
for seemingly no good reason) by <resolv.h>.
Yu Watanabe [Fri, 9 May 2025 02:18:02 +0000 (11:18 +0900)]
userdb: introduce USERDB_SYNTHESIZE_NUMERIC flag
When the flag is set, even if the specified UID/GID does not exist,
create a synthetic user record for the UID/GID.
Currently, only system UID/GID are supported.
With the commit, User=/Group=root was refused and warned that the root
is not a system user. Typically it is not necessary to specify such, but
let's not log confusing warning and honor the setting.
Yu Watanabe [Thu, 1 May 2025 03:44:23 +0000 (12:44 +0900)]
user-util,user-record-nss: initialize buffer before calling getpwnam_r() and friends
The buffer will be used by a library outside of our code base,
and may not be initialized even on success. Let's initialize
them for safety.
Hopefully fixes the following fuzzer warning:
```
==2039==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f9ad8be3ae6 in _nss_files_getsgnam_r (/lib/x86_64-linux-gnu/libnss_files.so.2+0x8ae6) (BuildId: 013bf05b4846ebbdbebdb05585acc9726c2fabce)
#1 0x7f9ad93e5902 in getsgnam_r (/lib/x86_64-linux-gnu/libc.so.6+0x126902) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
#2 0x7f9ad9b98153 in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:357:21
#3 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
#4 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29
Uninitialized value was created by a heap allocation
#0 0x556fd5294302 in malloc /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1021:3
#1 0x7f9ad9b9811d in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:353:23
#2 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
#3 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29
```
exec-util: make missing agents a gracefull handled issues
Just downgrade the log message in case of ENOENT of agent binaries to
LOG_DEBUG. Do this in order to support distros which split off some
agent bianries into separate optional binaries.
Todd C. Miller [Tue, 6 May 2025 22:39:14 +0000 (16:39 -0600)]
flush_ports: flush POSIX message queues properly
On Linux, read() on a message queue descriptor returns the message
queue statistics, not the actual message queue data. We need to use
mq_receive() to drain the queues instead.
Fixes a problem where a POSIX message queue socket unit with messages
in the queue at shutdown time could result in a hang on reboot/shutdown.