Igor Opaniuk [Thu, 23 Jan 2025 12:31:04 +0000 (13:31 +0100)]
sd-boot: use sysfail entry for UEFI firmware update failure
Add support for using a sysfail boot entry in case of UEFI firmware
capsule update failure [1]. The status of a firmware update is obtained from
the EFI System Resource Table (ESRT), which provides an optional mechanism
for identifying device and system firmware resources for the purposes of
targeting firmware updates to those resources.
Current implementation uses the value of LastAttemptStatus field from
ESRT, which describes the result of the last firmware update attempt for
the firmware resource entry. The field is updated each time an
UpdateCapsule() is attempted for an ESRT entry and is preserved across
reboots (non-volatile).
This can be be used in setups with support for A/B OTA updates, where
the boot firmware and Linux/RootFS might be updated synchronously.
[1] https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Igor Opaniuk [Mon, 24 Mar 2025 14:33:16 +0000 (15:33 +0100)]
bootctl: configure a sysfail entry
You can configure the sysfail boot entry using the bootctl command:
$ bootctl set-sysfail sysfail.conf
The value will be stored in the `LoaderEntrySysFail` EFI variable.
The `LoaderEntrySysFail` EFI variable would be unset automatically
during next boot by `systemd-boot-clear-sysfail.service` if no
system failure occured, otherwise it would be kept as it is and a system
failure reason will be saved to `LoaderSysFailReason` EFI variable.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Igor Opaniuk [Mon, 24 Mar 2025 14:30:49 +0000 (15:30 +0100)]
sd-boot: add support for a sysfail entry
Add support for a sysfail boot entry. Sysfail boot entries can be
used for optional tweaking the automatic selection order in case a
failure state of the system in some form is detected (boot firmware
failure etc).
The EFI variable `LoaderEntrySysFail` holds the boot loader entry to
be used in the event of a system failure. If a failure occurs, the reason
will be stored in the `LoaderSysFailReason` EFI variable.
sysfail_check() expected to be extented to support possible
conditions when we should boot sysfail("recovery") boot entry.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
This mostly makes sure we do something reasonable when our tool is
called from a boot of an entry that was already marked as definitely
"bad" on a previous boot. Such an entry we can return into a "good"
state, but we cannot return it into an "indeterminate" state, because
the status quo ante is already known.
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.
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.
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.
Yu Watanabe [Wed, 7 May 2025 12:44:22 +0000 (21:44 +0900)]
units: enable IgnoreOnIsolate=yes on systemd-udevd-kernel.socket
Otherwise, initrd-cleanup.service requests isolation thus the socket
is stopped before switching root, and several early events after
switching root may be lost.