Before this commit, when a .mount unit file is loaded, the device
dependencies from the unit file are automatically added. If a device
that is different from which specified in .mount unit file is mounted
on the path, then the device dependencies about the device are also added.
Hence, the unit has device dependencies about two (or more) different
devices. Hence, if one of the devices are unplugged, even if another one
is mounted on the path, then the path is unmounted.
This commit makes device dependencies from two different sources
exclusive, and always regenerate the dependencies when one of the
information is updated.
Fixes#19983 and #23552.
The dependencies tagged with UNIT_DEPENDENCY_MOUNTINFO_DEFAULT depend
on both /proc/self/mountinfo and corresponding .mount unit file.
Hence, if some information from mountinfo is updated, e.g. device mounted
on the path, we need to update the dependencies.
When the function mount_setup_new_unit() is called, the corresponding
.mount unit file is not loaded. Hence, Mount.from_fragment is false.
To add default dependencies to e.g. .device units, it is necessary that
the Mount.from_proc_self_mountinfo flag is set. However, the flag was
not set even the unit has information from /proc/self/mountinfo.
Partially fixes#19983.
Previously it was possible to set delegate property for scope, but you
were not able to allow unprivileged process to manage the scope's cgroup
hierarchy. This is useful when launching manager process that will run
unprivileged but is supposed to manage its own (scope) sub-hierarchy.
Fixes#21683
systemd-measure is not built without gnu-efi, which is the case, for
example, on ppc64le. Let's skip the relevant test case in this case
instead of failing.
```
The Meson build system
Version: 0.58.2
...
Host machine cpu family: ppc64
Host machine cpu: ppc64le
...
Message: Skipping systemd-measure.1 because HAVE_GNU_EFI is false
...
[ 115.711775] testsuite-70.sh[745]: + cat
[ 115.741996] testsuite-70.sh[832]: + /usr/lib/systemd/systemd-measure calculate --linux=/tmp/tpmdata1 --initrd=/tmp/tpmdata2
[ 115.754015] testsuite-70.sh[833]: + cmp - /tmp/result
[ 115.758004] testsuite-70.sh[832]: /usr/lib/systemd/tests/testdata/units/testsuite-70.sh: line 56: /usr/lib/systemd/systemd-measure: No such file or directory
[ 115.773851] testsuite-70.sh[833]: cmp: EOF on - which is empty
[ 115.983681] sh[835]: + systemctl poweroff --no-block
```
Adding Microsoft keys by default is recommended because firmware drivers
might be signed by it.
This also changes the file ending from .esl to .auth as that is used by
sign-efi-sig-list manpage and other sources.
Let's lock the backing fd instead of locking/unlocking multiple
times when doing multiple operations with repart. It doesn't make
much sense for anything else to touch the block device while there
are still repart operations pending on it. By keeping the lock over
the full duration of repart, we avoid anything else from interfering
with the block device inbetween operations.
crypt_init_data_device() replaces the crypt_device struct with a
new allocation, losing the old one, which we get from crypt_init().
Use crypt_set_data_device() instead.
Enhance the test to cover this option too.
This command takes a mountpoint, unmounts it and makes sure the
underlying partition devices and block device are removed before
exiting.
To mirror the --mount operation, we also add a --rmdir option which
does the opposite of --mkdir, and a -U option which is a shortcut
for --umount --rmdir.
On fast systems we might race against systemd and check the mount unit
after mounting it way too early before systemd had a chance to react to
the change.
```
[ 4.677701] H systemd[1]: Event source 0x210b3b0 (mount-monitor-dispatch) entered rate limit state.
...
[ 4.863731] H testsuite-64.sh[812]: + mount /logsysfsRxx
[ 4.865918] H kernel: EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.866213] H testsuite-64.sh[812]: + systemctl status /logsysfsRxx
[ 4.877502] H testsuite-64.sh[919]: ○ logsysfsRxx.mount - /logsysfsRxx
[ 4.877502] H testsuite-64.sh[919]: Loaded: loaded (/etc/fstab; generated)
[ 4.877502] H testsuite-64.sh[919]: Active: inactive (dead)
[ 4.877502] H testsuite-64.sh[919]: Where: /logsysfsRxx
[ 4.877502] H testsuite-64.sh[919]: What: /dev/disk/by-uuid/deadbeef-dead-dead-beef-222222222222
[ 4.877502] H testsuite-64.sh[919]: Docs: man:fstab(5)
[ 4.877502] H testsuite-64.sh[919]: man:systemd-fstab-generator(8)
[ 4.877502] H testsuite-64.sh[919]: Aug 03 10:10:10 H systemd[1]: logsysfsRxx.mount: Processing implicit device dependencies
[ 4.877502] H testsuite-64.sh[919]: Aug 03 10:10:10 H systemd[1]: logsysfsRxx.mount: Added Requires dependency on /dev/disk/by-uuid/deadbeef-dead-dead-beef-222222222222
[ 4.877502] H testsuite-64.sh[919]: Aug 03 10:10:10 H systemd[1]: logsysfsRxx.mount: Added StopPropagatedFrom dependency on /dev/disk/by-uuid/deadbeef-dead-dead-beef-222222222222
[ 4.895683] H sh[920]: + systemctl poweroff --no-block
[ 4.906533] H systemd[1]: Found unit logsysfsRxx.mount at /run/systemd/generator/logsysfsRxx.mount (regular file)
[ 4.906594] H systemd[1]: Preset files don't specify rule for logsysfsRxx.mount. Enabling.
[ 4.906990] H systemd[1]: testsuite-64.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
[ 4.907057] H systemd[1]: testsuite-64.service: Failed with result 'exit-code'.
[ 4.907287] H systemd[1]: Failed to start testsuite-64.service.
[ 4.955293] H systemd[1]: Starting end.service...
[ 4.955736] H systemd-logind[809]: The system will power off now!
[ 4.955868] H systemd-logind[809]: System is powering down.
[ 4.975781] H systemd[1]: Event source 0x210b3b0 (mount-monitor-dispatch) left rate limit state.
[ 4.975821] H systemd[1]: logsysfsRxx.mount: Processing implicit device dependencies
[ 4.975857] H systemd[1]: logsysfsRxx.mount: Added Requires dependency on /dev/vda2
[ 4.975893] H systemd[1]: logsysfsRxx.mount: Added StopPropagatedFrom dependency on /dev/vda2
[ 4.975928] H systemd[1]: Unit blockdev@dev-vda2.target has alias blockdev@.target.
[ 4.975967] H systemd[1]: logsysfsRxx.mount: Added After dependency on /dev/vda2
[ 4.976081] H systemd[1]: logsysfsRxx.mount: Changed dead -> mounted
```
The llvm bpf compiler appears to place const volatile variables in
a non-standard section which creates an incompatibility with the gcc
bpf compiler.
To fix this force GCC to also use the rodata section.
Note this does emit an assembler warning:
Generating src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.unstripped.o with a custom command
/tmp/ccM2b7jP.s: Assembler messages:
/tmp/ccM2b7jP.s:87: Warning: setting incorrect section attributes for .rodata
See:
https://github.com/llvm/llvm-project/issues/56468
Fixes:
../src/core/restrict-ifaces.c:45:14: error: ‘struct
restrict_ifaces_bpf’ has no member named ‘rodata’; did you mean
‘data’?
45 | obj->rodata->is_allow_list = is_allow_list;
| ^~~~~~
| data
According to the C++ ISO standard, a conformant compiler is allowed to
define this macro to any value for any reason as it is implementation
defined: https://timsong-cpp.github.io/cppwp/cpp.predefined#2.3
This mean that it cannot be assumed that it is not defined in a C++.
Change the condition to reflect that.
***DANGER*** NOTE ***DANGER***
This feature might result in your device becoming soft-brick as outlined
below, please use this feature carefully.
***DANGER*** NOTE ***DANGER***
If secure-boot-enrollment is set to no, then no action whatsoever is performed,
no matter the files on the ESP.
If secure boot keys are found under $ESP/loader/keys and secure-boot-enrollment
is set to either manual or force then sd-boot will generate enrollment entries
named after the directories they are in. The entries are shown at the very bottom
of the list and can be selected by the user from the menu. If the user selects it,
the user is shown a screen allowing for cancellation before a timeout. The enrollment
proceeds if the action is not cancelled after the timeout.
Additionally, if the secure-boot-enroll option is set to 'force' then the keys
located in the directory named 'auto' are going to be enrolled automatically. The user
is still going to be shown a screen allowing them to cancel the action if they want to,
however the enrollment will proceed automatically after a timeout without
user cancellation.
After keys are enrolled, the system reboots with secure boot enabled therefore, it is
***critical*** to ensure that everything needed for the system to boot is signed
properly (sd-boot itself, kernel, initramfs, PCI option ROMs).
This feature currently only allows loading the most simple set of variables: PK, KEK
and db.
The files need to be prepared with cert-to-efi-sig-list and then signed with
sign-efi-sig-list.
Here is a short example to generate your own keys and the right files for
auto-enrollement.
`
keys="PK KEK DB"
uuid="{$(systemd-id128 new -u)}"
for key in ${keys}; do
openssl req -new -x509 -subj "/CN=${key}/ -keyout "${key}.key" -out "${key}.crt"
openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"
cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl.nosign"
done
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl.nosign PK.esl
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl.nosign KEK.esl
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl.nosign db.esl
`
Once these keys are enrolled, all the files needed for boot ***NEED*** to be signed in
order to run. You can sign the binaries with the sbsign tool, for example:
`
sbsign --key db.key --cert db.crt bzImage --output $ESP/bzImage
`
Example:
Assuming the system has been put in Setup Mode:
`
$ESP/loader/keys/auto/db.esl
$ESP/loader/keys/auto/KEK.esl
$ESP/loader/keys/auto/PK.esl
$ESP/loader/keys/Linux Only/db.esl
$ESP/loader/keys/Linux Only/KEK.esl
$ESP/loader/keys/Linux Only/PK.esl
$ESP/loader/keys/Linux and Windows/db.esl
$ESP/loader/keys/Linux and Windows/KEK.esl
$ESP/loader/keys/Linux and Windows/PK.esl
`
If auto-enroll is set, then the db, KEK and then PK are enrolled from the 'auto'
directory.
If not, three new boot entries are available to the user in order to enroll either the
'Linux Only', 'Linux And Windows' or 'auto' set of keys.
Now the console_fd of user service manager is 2. Even if LogTarget=console is set in /etc/systemd/user.conf,there is no log in the console.
This reopen the /dev/console, so the log of user service can be output in the console.
Via the "backing_fd" variable we intend to pin the backing inode through
our entire code. So far we typically created the fd via F_DUPFD_CLOEXEC,
and thus any BSD lock taken one the original fd is shared with our
backing_fd reference. And if the origina fd is closed but our backing_fd
is not, we'll keep the BSD lock open, even if we then reopen the block
device through the backing_fd. If hit, this results in a deadlock.
Let's fix that by creating the backing_fd via fd_reopen(), so that the
locks are no longer shared, and if the original fd is closed all BSD
locks on it that are in effect are auto-released.
(Note the deadlock is only triggered if multiple operations on the same
backing inode are executed, i.e. factory reset, resize and applying of
partitions.)
Replaces: #24181
Inspired by: https://github.com/systemd/systemd/pull/24141
Calling fd_is_mountpoint() with AT_EMPTYPATH and an empty filename can
only work if we have new statx() available. If we do not, we can still
make things work for directories, but not for other inodes (since there
we cannot query information about the parent inode to compare things.)
Hence, let's handle and test this explicitly, to support this to the
level this is possible.
Since the library is dlopen()ed by libpthread and required during
pthread_exit()/pthread_cancel(), let's install it explicitly if available to
avoid unexpected fails in tests. This also consolidates all related
workarounds for this library across the test scripts.
With this update, Arch Linux keyring updates will be automatically
pulled in instead of having to update to a new mkosi commit every
time the keyring gets outdated.
