core/manager: port to notify_recv_with_fds()

shared/async: introduce asynchronous_close_many() helper

notify-recv: several followups

Follow-up for 7f6af95dab037e7d15591a924dbf256460bbf069

- Allocate internal buf on the stack, memdup() only at the end.
  This ensures we're able to handle OOM gracefully, i.e.
  return -EAGAIN on OOM while still emptying socket buffer.
- Do not treat empty notify message as error.
- Raise log level since all callers log loudly anyway.

udev_device_has_tag: fix typo

udev,sd-device: always use synthetic UUID when triggering uevent (#36514)

This drops support of kernels older than 4.13.

tpm2-setup: two fixes for tmpfile handling (#36521)

sd-device: always pass random UUID on triggering uevent

Then, this makes sd_device_trigger() a simple wrapper of
sd_device_trigger_with_uuid().

udevadm-trigger: drop support of kernels order than 4.13

Now our kernel baseline is 5.4, hence we can always write action string
with a synthetic UUID.

udev-builtin-uaccess: modernize code

No functional change, just refactoring.

udev-util: drop unnecessary inclusion of missing_threads.h

Follow-up for a3df693799499a26735acc1f0c4f1b5d1f182fa7.

doc: add document explaining the 3 key components of the boot and how we find the rootfs

After the network boot PR got merged we can use some more high-level
docs I guess.

tpm2-setup: remove redundant fflush_and_check()

The immediately following flink_tmpfile() does that anyway, hence no
need to do so explicitly beforehand.

(Also the log message was wrong: it says "sync" but here we "flush",
which is a much weaker operation)

tpm2-setup: add missing O_CLOEXEC at two places

copy: Invoke hardlink context cleanup before restoring timestamps

When hardlink recreation is requested, it creates temporary files that
will be deleted once the context is destroyed. The deletion
(potentially) updates the directory's timestamps, so it's crucial that
the deletion happens before the directory timestamps are restored when
`COPY_RESTORE_DIRECTORY_TIMESTAMPS` is requested.

timesync: several trivial cleanups (#36506)

sd-bus: sort enumerated child objects (#36507)

Fixes #8008.

make integritysetup/veritysetup more alike cryptsetup when it comes to remote operation (#36501)

Let's address some asymmetries here.

systemd-boot: some refactorings (#36510)

Clean up systemd-boot a bit. Mostly makes handling of some menu entry
types less magic and more uniform. Doesn't really change behaviour in
any ways, except that we now condition things such as boot counting,
random seed management and entry selection saving carefully on the entry
type.

packit: Switch to meson.version for the current version (#36509)

integritysetup: add remote-integritysetup.target to match remote-{crypt|verity}setup.target

Let's make the three subsystems more alike, and add remote-*setup.traget
for all three, enable them all three in the presets, and make them
behave in a similar fashion.

preset: enable remote verity targets too

Let's make cryptsetup and veritysetup more symmetric, and enable the
remote target for the latter the same way we enable the remote target
for the former by default.

boot: split out call that adds reboot/poweroff/firmware entries

boot: make secure boot enrollment less special

This is the last entry type that has special handling: with this in
place we now always invoke entry handlers the very same way. via the
.call() method of the BootEntry structure.

boot: move check if secure boot enrollment applies to a single place

Let's check if sb enrollment applies at a single place: inside the
discovery function, and let's not bother with additional checks later.

boot: make regular entries less special

Let's try to always invoke entries via the call() method of BootEntry
objects, to stick to a single uniform way to do so.

boot: only save entry for some entry types

Much like the previous one, let's also condition the entry selection
saving on entry types.

boot: only do random seed management for some entry types

Similar to the previous commits, let's carefully condition random seed
management (which might be slow, and simply pointless for various entry
types) on the entry type.

boot: only do boot counting management for some menu entries

Let's do boot counting only for some menu entry types, and carefully
list which types those are.

boot: make .call() method of BootEntry more complete

Let's pass some context information to the .call() methods so that it's
sufficient to implement the handlers for all entry types with them.

(This commit doesn't port the various entry types over though, that
happens in later commits.)

boot: split out line editor

let's make this beast of boot.c a bit more digestable

packit: Switch to meson.version for the current version

mkosi: update fedora commit reference

* 9b6884d2e1 Stop using version_no_tilde for github archives
* 5671cf6132 List the fallback Source0 first

meson: add more space for sections

I ran into the limit with ParticleOS, with 6 profiles, hence I think the
current default value is a bit low. let's bump it 4x, to 120. This is
still a lot lower than 500 or so which Debian uses downstream.

We can look into raising this further should we collide with this again,
but for now, let's try 120 and see how it goes in practice.

test-bus-object: check if enumerated objects are sorted

sd-bus: sort enumerated child objects

Fixes #8008.

update TODO

mkosi: Enable History= option (#36500)

This option makes mkosi "remember" all the CLI options specified on the
command line when building an image. This means they don't need to be
specified again when booting the image afterwards or doing any other
operation on the image with "mkosi xxx".

As an example of how this is useful, currently, when running "mkosi -d
opensuse -f" to build an opensuse image and then running "mkosi sandbox
-- meson test -C build TEST-86-MULTI-UKI-PROFILE", running the test will
try to add virtiofs mounts of the fedora~rawhide build directory on my
machine instead of the opensuse one. With the History= option enabled,
it will use the opensuse tumbleweed directory as expected.

mkosi: Enable History= option

This option makes mkosi "remember" all the CLI options specified on
the command line when building an image. This means they don't need
to be specified again when booting the image afterwards or doing any
other operation on the image with "mkosi xxx".

As an example of how this is useful, currently, when running "mkosi
-d opensuse -f" to build an opensuse image and then running "mkosi
sandbox -- meson test -C build TEST-86-MULTI-UKI-PROFILE", running
the test will try to add virtiofs mounts of the fedora~rawhide build
directory on my machine instead of the opensuse one. With the History=
option enabled, it will use the opensuse tumbleweed directory as expected.

We stop setting --extra-search-path and --output-dir in the integration test
wrapper as these are settings that are "remembered" by enabling the History=
option.

test: Do not add integration tests if want_tests == 'false'

bootctl-install: Use i2d_PKCS7() instead of i2d_PKCS7_SIGNED()

For a detached signature, these are equivalent so let's use i2d_PKCS7()
like we do everywhere else.

TEST-64-UDEV-STORAGE: Stop using mkosi configure scripts

Now that we have mkosi sandbox, meson runs with the mkosi tools tree
mounted (if one is used at all), so we can implement all the qemu feature
checks in meson itself, removing the need for mkosi configure scripts.

TEST-53-ISSUE-16347: Implement rtc via custom argument

Let's get rid of the configure script for this use case by just
implementing the necessary logic in integration-test-wrapper.py.
We need to get rid of our usage of configure scripts to allow enabling
the History= setting.

mkosi: Update to latest

timesync: add short comment for boolean argument

timesync: drop meaningless boolean flag

The boolean flag is always true, as manager_save_time_and_rearm() is
called unconditionally.

Follow-up for 33e82f3ef33a2497f9838a5fbb924c7501d8dd9e.

timesync: use event_reset_time_relative()

No functional change, just refactoring.

fuzz: decompress_startswith() may return zero (#36490)

Also, disables fuzz-compress on oss-fuzz.
Fixes #36472.

repart: when using erofs and log level is not debug, use --quiet

mkfs.erofs is extremely verbose and will log every single file added
to the filesystem, which is a lot of them when building a rootfs.

systemd-keyutil: add verb to conver PKCS#1 to PKCS#7

Add verb that takes a PKCS#1 signature (plain rsa) as input and a
certificates, and outputs a PKCS#7 binary detached signature (p7s),
which is what the kernel dm-verity driver expects.

Co-authored-by: Luca Boccassi <bluca@debian.org>

fstab-util: port use of setmntent() and friends to libmount (#36489)

sd-event: pidfdize sd_event_source_send_child_signal()

Follow-up for c6cc7efcd35f729cf0db8f8502752c7d83a0be95

The documentation has been updated, but apparently I forgot
to update the function itself...

Also, actually pass flags to pidfd_send_signal(). Previously
it was spuriously ignored.

fuzz: tentatively disable fuzz-compress on oss-fuzz

It does not work on oss-fuzz for some reasons. See #11018.

fuzz: decompress_startswith() may return zero

Fixes #36472.

sd-event: always operate on child source via pidfd (#36480)

fstab-util: port use of setmntent() and friends to libmount

libmount-util: introduce libmount_parse_fstab() wrapper

fstab-util: join 'filtered' only if requested by caller

sbsign: Don't set bit in SpcPeImageData->flags

Neither sbsign nor pesign set this flag in SpcPeImageData->flags,
which is about which resources should be included specifying "Which
portions of the Windows PE file are hashed." according to the
authenticode spec. However, this is followed by "Although flags is
always present, it is ignored when calculating the file hash for both
signing and verification purposes". So as it doesn't seem to do
anything useful and the other tools don't set any of these flags
either, let's follow suite and not set this flag ourselves either.

hwdb: add axis range corrections for the Lenovo Yoga Slim 7 14ARE05

mkosi: add libapparmor1 to package list for opensuse

TEST-02-UNITTESTS.sh[4381]: [ 2329.636166] test-dlopen-so[650]: libapparmor.so.1 is not installed: libapparmor.so.1: cannot open shared object file: No such file or directory
TEST-02-UNITTESTS.sh[4381]: [ 2329.636174] test-dlopen-so[650]: Assertion 'dlopen_libapparmor() >= 0' failed at src/test/test-dlopen-so.c:103, function run(). Aborting.

Follow-up for 384949f7dee164c2c3cfd78f94a5f27b61fb7c28

Coding style followups (#36476)

process-util: refuse FORK_WAIT + FORK_FREEZE combination

sd-event: always operate on child source via pidfd

Follow-up for 6e14c46bac760d01868b0bf48461f6ac44c86be3

Nowadays a pidfd is guarenteed to be around for child
event sources, hence drop the effectively unused pid-based
branches.

Addresses https://github.com/systemd/systemd/pull/36410#discussion_r1959930716

sd-event: assert on hashmap_remove(child.pid)

Follow-up for 54988a27b9d1487e1690f94b79031ef61edd6651
and a342c71d360e083b3f6b06a64d852c4e3aceeef3

process-util: introduce SIGINFO_CODE_IS_DEAD helper

docs/CONTROL_GROUP_INTERFACE: fix typo

udev-builtin-blkid: merge var definitions, fix grammar

Follow-up for f8825c1364fb1c3f3f5d96654e779fd51500f476

basic/utf8: add missing assertion

Follow-up for 104a6b8c390730f66f5acbcaefbc27898bfef9fe

basic/strv: minor coding style follow-ups

Follow-up for 428146dc89506725f777ae82d288439340926a83

Addresses https://github.com/systemd/systemd/pull/36271#discussion_r1958334800

core: dlopen()'ify libapparmor

In Arch Linux we currently have a half-baked apparmor support,
in particular we cannot link systemd to libapparmor for service
context integration, since that will pull apparmor into base system.
Hence, let's turn this into a dlopen dep.

Ref: https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/issues/22

Support booting from rootfs acquired via HTTP (#36314)

This extends systemd-import-generator to not only download a disk image
at boot, but also attach it to a loopback device, so that we can boot
from it.

We have most of the pieces already in place, this just polishes some
things, to make this round.

The topmost commit contains example command lines that just work to make
`systemd-vmspawn` boot from a `mkosi serve` call.

Note that this does not address how to get the UKI running on the target
system, this only deals with the later boot phase once the UKI is
already running.

This is WIP, because it lacks docs, and I want to do some more
polishing. But it works great.

Ultimate goal, provide a complete solution so that we also can do uefi
http boot for ukis

update TODO

boot: when we detect that sd-boot is called as NBP, print friendly message

Fixes: #11850

sd-boot: also read type #1 entries from SMBIOS Type #11

With this we can now do:

systemd-vmspawn -n -i foobar.raw -s io.systemd.boot.entries-extra:particleos-current.conf=$'title ParticleOS Current\nuki-url http://example.com/somedir/uki.efi'

Assuming sd-boot is available inside the ESP of foobar.raw a new item
will show up in the boot menu that allows booting directly into the
specified UKI.

vmspawn: simplify cmdline_add_vsock() a tiny bit

vmspawn: add --smbios11= switch for passing arbitrary smbios type #11 strings to vm

vmspawn: split out code that appends kernel command line into its own helper

boot: add new 'uki-url' bls type #1 menu items for booting remote UKIs

Companion BLS spec PR:

https://github.com/uapi-group/specifications/pull/135

boot: add new bls type #1 stanza "uki"

This one is between "efi" and "linux": we'll recognize such entries as
linux, but we'll just invoke them as EFI binaries.

This creates a high-level concept for invoking UKIs via indirection of a
bls type #1 entry, for example to permit invocation from a non-standard
path or for giving entries a different name.

Companion BLS spec PR:

https://github.com/uapi-group/specifications/pull/135

(Let's rename LOADER_UNIFIED_LINUX to LOADER_TYPE2_UKI at the same time
to reduce confusion what is what)

boot: move behaviour checks into per-entry-type helpers

boot: be stricter when filtering out invalid bls #1 entries

boot: bls type #1 with 'efi' stanza are bls type #1 too

efi: add strcspn16()/strspn16() to efi libs too

efi-string: add new xstr16_to_ascii() helper

efi: modernize reconnect_all_drivers() a bit

gpt-auto-generator: if root=gpt-auto is specified on kernel cmdline, always wait for /dev/gpt-auto-root symlink

So far our login in gpt-auto-generator when run in the initrd has been
to generate the units that wait for /dev/gpt-auto-root to show up and
mount them only if we have the loader partition EFI variables set. This
is of course not the case for network boots with a UKI kernel, which
means auto-gpt would not work for mounting the rootfs.

What's nasty is that we don't know for sure whether the "rootdisk"
loopback device will shown up eventually, as it needs explicit
configuration by the user via the kernel cmdline, or could be configured
entirely indepdenently. Hence, let's tweak the logic when we wat for
/dev/gpt-auto-root as device to mount: make the gpt auto root logic a
tristate: if root=gpt-auto is specified on the cmdline *definitely*
enable the logic. If root= is specified and set to anyting else,
*definitely* disable the logic. And if root= is not specified check for
the EFI partition vars – as before – to conditionalized things.

Or in other words, you can now boot the same image either via ESP/local
boot or via netboot with a kernelcmdline image like this:

    rd.systemd.pull=verify=no,machine,blockdev,bootorigin,raw:rootdisk:image.raw root=gpt-auto rootflags=x-systemd.device-timeout=infinity ip=any

udev-builtin-blkid: use loopback block device 'ref' field fo determining gpt-auto whole block device

So far the gpt-auto logic only looked for the partition table of devices
that the ESP/XBOOTLDR partition used to boot was on. This works great
for local boots, but is more problematic if we boot a UKI via UEFI HTTP
boot, because there is no ESP in play in that case.

Let's introduce an alternative to communicate the intended default root
disk to cover for this situation: any loopback block device whose
backing file field (i.e. the userspace controlled freeform field we use
for /dev/disk/by-loop-ref/ naming) is set to "rootdisk" will be consider
for gpt-auto will be consider for gpt-auto.

With this in place we should have nice automatic behaviour:

1. If we are booted locally we'll get the ESP/XBOOTLDR data, and derive
   the root disk from that.

2. If we are booted via UEFI HTTP boot we expect that the caller makes
   the loopback device appear with the right loop-ref identifier, and
   then will use that.

import-generator: give import services better names

Previously, we'd name the import services numerically. Let's instead use
the local target file name, i.e. the object we are creating with these
services locally. That's useful so that we can robustely order against
these service instances, should we need to one day.

fstab-generator: validate root= and mount.usr= the same way

In both cases, let's check for the same special mount sources. We
already covered some of the same, but let's just make it the same
codepaths.

fstab-generator: support creating bind mounts via root= kernel cmdline switches

This is useful for bind mounting a freshly downloaded and unpacked tar
disk images to /sysroot to mount into.

Specifically, with a kernel command line like this one:

  rd.systemd.pull=verify=no,machine,tar:root:http://_gateway:8081/image.tar root=bind:/run/machines/root ip=any

The first parameter downloads the root image, the second one then binds
it to /sysroot so that we can boot into it.

import-generator: optionally import images into /run/ hierarchy rather than /var/

This is useful in particular in the initrd, as this ensures any
downloaded images are not deleted during the initrd→host transition
(where /var/ does not survive, but /run/ does). Might be useful in other
cases too, for example for transiently deployed confexts and such.

importd: optionally allow clients to specify alternative image root

import-generator: add new option 'bootorigin' to derive URL from efi boot url

sd-stub: if we are http booted, query source URL and write to EFI variable

This way userspace can read the field, and use it to retrieve more
resources from the same place.

import-generator: optionally create loopback devices after download

This is useful for booting from a freshly downloaded disk image: just
specify

    rd.systemd.pull=verify=no,machine,blockdev,raw:image:https://192.168.100.1:8081/image.raw
    root=/dev/disk/by-loop-ref/image.raw-part2

on the kernel command line, and we'll download that in the initrd and boot from it.

(note the above disables download-time verification, putting trust in
verity and image policy that this won#t do harm)

Here's a more complete example. From a git checkout do:

    ninja -C build && mkosi -f -T serve

and then from another terminal do within the same checkout:

    ./build/systemd-vmspawn \
            --ram=16G \
            --register=no \
            -n \
            -i ./build/mkosi.output/image.raw \
            rd.systemd.pull=verify=no,machine,blockdev,raw:image:http://192.168.100.1:8081/image.raw \
            root=/dev/disk/by-loop-ref/image.raw-part2 \
            rootflags=x-systemd.device-timeout=infinity \
            ip=any

This will then boot via the ESP of the specified image, then download
the image via HTTP from the mkosi instance running in the first
terminal, attach it to a loopback block device, and then use its second
partition as root fs, and boot into it.

(this assumes your host is 192.168.100.1, of course)

Note that downloading the full image takes a bit of time (this downloads
it uncompressed after all), hence we turn off the timeout to wait for
the device.

This also introduces a new "imports.target" unit (and associated
"imports-pre.target") between imports are grouped, and which ensure the
imports actually are ordered correctly both on the host and in the
initrd.

man: mention 'rd.' prefix for import-generator kernel cmdline options

units: add generic service for attaching a file to a loopback device

This is mostly just a friendly unit wrapper around "systemd-dissect
--attach".

This is useful so that we can automatically attach disk images as
block device at boot.

dissect: add --quiet mode

dissect: optionally derive loop-ref from image filename

mkosi: add kernel-bootcfg to all images

kernel-bootcfg --add-uri= is just too useful when playing with network
boot. Let's just add it to our images.