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.
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.
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.
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.
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.
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.
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.
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.
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 384949f7de
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
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
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)
