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.
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.
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.
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.)
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>
Follow-up for c6cc7efcd3
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.
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.
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
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.
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)
Lennart Poettering
Yu Watanabe
Daan De Meyer
Luca Boccassi
Dan StreetmanandLuca Boccassi
Mike Yuan