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
