efi-loader: split efi-api.[ch] from efi-loader.[ch]
Some refactoring: split efi-loader.[ch] in two: isolate the calls that
implement out boot loader interface spec, and those which implement
access to upstream UEFI firmware features.
They are quite different in nature and behaviour, and even semantically
it makes to keep these two separate. At the very least because the
previous name "efi-loader.[ch]" suggests all was about loader-specific
APIs, but much of it is generic uefi stuff...
While we are at it, I renamed a bunch of return parameters to follow our
usual ret_xyz naming. But besides renaming no real code changes.
On systems lacking EFI or the SecureBoot efi var the caching of this
info didn#t work, since we'd see ENOENT when reading the var, and cache
that, which we then use as reason to retry next time.
Let's fix that and convert ENOENT to "secure boot", because that's what
it really means. All other errors are left as is (and reason to retry).
But let's add some debug logging for that case.
Yu Watanabe [Tue, 22 Mar 2022 13:01:08 +0000 (22:01 +0900)]
network: do not enable IPv4 ACD for IPv4 link-local address if ACD is disabled explicitly
The commit 1cf4ed142d6c1e2b9dc6a0bc74b6a83ae30b0f8e makes the IPv4 ACD
enabled unconditionally for IPv4 link-local addresses even if users
explicitly disable ACD.
This makes the IPv4 ACD is enabled by default, but honor user setting.
Frantisek Sumsal [Fri, 11 Mar 2022 08:19:29 +0000 (17:19 +0900)]
lgtm: disable cpp/missing-return (again)
It looks like the fix for https://github.com/github/codeql/issues/8409
is not yet in production (and the respective query needs to be enabled
in both the main and the PR branch to get results for it, hence why it
passed in #22837).
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
meson: replace sh+find with an internal glob in the python helper
As suggested in https://github.com/systemd/systemd/pull/22810#discussion_r831708052
This makes the whole thing simpler. A glob is passed to helper which then resolves
it on its own. This way it's trivial to call the helper with a different
set of files for testing.
tools/dbus_exporter: deblackify and shorten code a bit
When we do mkdir, we should just use 0o777 and let the umask take care of the
rest. Specifying an explicit mode is inappropriate. And when touching the code,
let's replace black madness with normal python style.
Nishal Kulkarni [Sun, 13 Mar 2022 19:05:18 +0000 (00:35 +0530)]
core/oomd: Use oom-kill ServiceResult for oomd
To notify user of kill events from systemd-oomd we now use
`SERVICE_FAILURE_OOM_KILL` as the failure result.
`unit_check_oomd_kill` now calls `notify_cgroup_oom` to
update the service result to `oom-kill`.
We add a new xattr `user.oomd_ooms` to keep track of the OOM kills
initiated by systemd-oomd, this helps us resolve a race between sending
SIGKILL to processes and checking for OOM kill status from the xattr.
random-util: use correct minimum pool size constant
The actual minimum size of the pool across supported kernel versions is
32 bytes. So adjust this minimum.
I've audited every single usage of random_pool_size(), and cannot see
anywhere that this would have any impact at all on anything. We could
actually just not change the constant and everything would be fine, or
we could change it here and that's fine too. From both a functionality
and crypto perspective, it doesn't really seem to make a substantive
difference any which way, so long as the value is ≥32. However, it's
better to be correct and have the function do what it says, so clamp it
to the right minimum.
systemd-udev-trigger.service by default triggeres all devices regardless
of whether they were already recognized by systemd-udevd.
There are machines (especially in embedded environments) where
systemd-udev-trigger.service is configured to run at a later stage of
the boot sequence, which can lead to quite a lot of devices being
triggered although they were already recognized by systemd-udevd.
Re-triggering a lot of devices is a relatively expensive operation and
therefore should be avoided if unnecessary.
Therefore this patch introduces --initialized-nomatch, which filters out
devices that are already present in the udev database. For consistance
reasons --initialized-match is implemented as well, which filters out devices
that are *not* already present in the udev database.
Yu Watanabe [Sat, 19 Mar 2022 00:35:32 +0000 (09:35 +0900)]
sd-device-enumerator: drop /sys/subsystem support
This addresses the comment by Lennart
https://github.com/systemd/systemd/pull/22662#discussion_r829799863:
> /sys/subsystem is preparation for a future that never came.
> And given that the main proponent of this left Linux kernel
> development (Kay), I doubt this will ever come. So maybe we
> should start dropping references to /sys/subsystem/ given it's
> unlikely to materialize anytime soon.
docs: add /loader/entries.srel to the boot loader spec
This new file is supposed to address conflicts with Fedora/Grub's
frankenbootloaderspec implementation, that squatted the /loader/entries/
dir, but place incompatible files in them (that do variable expansion?).
A simple text file /loader/entries.srel shall indicate which spec is
implemented. If it contains the string "type1\n" then the
/loader/entries/ directory implements our standard spec, otherwise
something else.
man: also install systemd-stub man page as sd-stub
So, typically systemd-boot is referenced as sd-boot, due to te usual
shorter naming in ESP resources. systemd-stub didnt do that so far,
since it never appears as separate files in the ESP. However it's super
annoying that you can find "man sd-boot", but not the very closely
related "man sd-stub". Let's fix that, and also add an "sd-stub" alias
to the "systemd-stub" man page.
man: clarify where the settings in type #1 entries are documented
So (maybe weirdly) loader.conf(5) documents both loader.conf and type #1
entries (because they share a similar syntax). But it then only lists
the options of loader.conf. Let's add an explicit hint where to find
the documentation of the type #1 entries.
NEWS: try to fix old entry regarding KERNEL_INSTALL_LAYOUT
The old text was simply wrong, we used to read $layout from
/etc/kernel/install.conf and the machine ID from
$KERNEL_INSTALL_MACHINE_ID from /etc/machine-info. Correct that.
Apparently KERNEL_INSTALL_MACHINE_ID was already known back in v235
times, hence don't mention it anymore.
it's kinda weird retro-fixing these NEWS entries, given we deprecate
them again, but I couldn't let this really incorrect stuff be.
bootctl: load /etc/kernel/install.conf's $layout field, too
bootctl so far tried to determine the layout from /etc/machine-info, but
that's obsolete, and the kernel-install script never looked there. Let's
read the setting from /etc/kernel/install.conf instead, where
kernel-install actually looks.
Support for reading the field from /etc/machine-info is retained for
compat.
This means we'll now read /etc/machine-id, /etc/machine-info and
/etc/kernel/install.conf, and read the machine ID from the former too
and the layout setting from the latter two.
journal-file: port journal_file_open() to openat_report_new()
We so far had some magic logic in place that files we open for write
with size zero are freshly created. That of course is a bogus
assumption, in particular as this code deals with corrupted file systems
which oftentimes contain zero size inodes from left-over runs.
Let's fix this properly, and actually let the kernel tell us whether it
create the file or not.
fs-util: add openat_report_new() wrapper around openat()
This is a wrapper around openat(). It works mostly the same, except for
one thing: it race-freely reports whether we just created the indicated
file in case O_CREAT is passed without O_EXCL.
basic/strv: avoid potential UB with references to array[-1]
"""
Given an array a[N] of N elements of type T:
- Forming a pointer &a[i] (or a + i) with 0 ≤ i ≤ N is safe.
- Forming a pointer &a[i] with i < 0 or i > N causes undefined behavior.
- Dereferencing a pointer &a[i] with 0 ≤ i < N is safe.
- Dereferencing a pointer &a[i] with i < 0 or i ≥ N causes undefined behavior.
"""
As pointed by by @medhefgo, here we were forming a pointer to a[-1]. a itself
wasn't NULL, so a > 0, and a-1 was also >= 0, and this didn't seem to cause any
problems. But it's better to be formally correct, especially if we move the
code to src/fundamental/ later on and compile it differently.
Compilation shows no size change (with -O0 -g) on build/systemd, so this should
have no effect whatsoever.