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.)
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)
Follow-up for 97318131fd.
By default, suite of each built test is determined by the directory of
the source file. Hence, before the mentioned commit, all tests in
src/boot/efi/ are in the 'efi' suite. The commit changed the directory
tree, but forgot to update the name of the test suite.
This also
- renames efifirmware_match_by_fwid() -> efi_firmware_match_by_fwid(),
- drops unnecessary wrapper efifw_get_fwid(),
- drops unnecessary inclusion of header <endian.h>,
- sort files in meson.build.
No functional change, just refactoring and follow-ups for
83bf58f39d.
UKIs can be used to bundle uefi firmwares that can be measured and
used on a confidential computing environment. There can be more than one
firmware blob bundle, each one for a specific platform. Also firmware images
can themselves be containers like IGVM files that can in turn bundle the
actual firmware blob. This change is specifically for uefi firmwares, not
IGVM container files.
This change adds support to introduce a .efifw section in UKI that can be
used for firmware blobs/images. There can be multiple such sections and each
section can contain a single firmware image.
The matching .hwids entry for a specific platform can be used to select the
most appropriate firmware blob.
ukify tool has been also changed to support addition of a firmware image
in UKI.
Since firmware gets measured automatically, we do not need to measure it
separately as a part of the UKI.
This fixes the following error:
In file included from ../src/basic/macro.h:13,
from ../src/basic/env-util.h:9,
from ../src/nss-systemd/nss-systemd.c:7:
../src/fundamental/macro-fundamental.h:61:9: error: option ‘-Wzero-as-null-pointer-constant’ is valid for C++/ObjC++ but not for C [-Werror=pragmas]
61 | _Pragma("GCC diagnostic ignored \"-Wzero-as-null-pointer-constant\"")
| ^~~~~~~
../src/nss-systemd/nss-systemd.c:106:1: note: in expansion of macro ‘DISABLE_WARNING_ZERO_AS_NULL_POINTER_CONSTANT’
106 | DISABLE_WARNING_ZERO_AS_NULL_POINTER_CONSTANT;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
This was added originally as it was thought that Windows applied
the same cap. Nowadays the specs do not mention it, and it is
believed Windows no longer applies it either, so drop it in order
to allow an arbitrary number of DTBs to be included
Fixes https://github.com/systemd/systemd/issues/35943
When devices of different types are present, chid_match() should only try to
match the devices that are of specific type. The caller of chid_match()
provides the type of device to match against and chid_match() should only try
to find a match against this device type.
This change also adds necessary unit test changes for the new uefi firmware
type device entry.
This is a follow-up for f8fa4222c9 (boot: Make
initrd_prepare() semantically equivalent to combine_initrds()). That commit
changed the way that the initrd is prepared for type#1 boot loader entries,
also effectively rounding up the sizes to a multiple of 4. In [1], downstream
packagers report that the trailing zeroes result in the calculated hash being
different. To restore compatibility with previous hash calculations and
signatures, change the reported size by excluding the trailing padding. This
should restore the calculation results for the case where only one initrd is
used.
This patch doesn't touch the stub, i.e. doesn't change behaviour for UKIs. The
seems fine, since we didn't change that recently, so any changes there would
break compatiblity. The measurement results for type#1 and type#2 entries are
generally going to be different anyway. ukify and systemd-measure are also out
of scope here, because they are for UKIs.
Fixes https://github.com/systemd/systemd/issues/35439.
The other changes to the way the initrd is constructed are kept, so hopefully
the original issue with booting in qemu is not recreated.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1233752
My simple test: I'm booting a QEMU VM with systemd-boot and a type#1 entry.
With old systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - aec1aee5358bde36f5498f2dc243dec2b103f81242de57b887a11f53677f1272 F - Linux: initrd
With updated systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - 3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 F - Linux: initrd
This matches the initrd hash:
$ sudo sha256sum /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
A previous commit accidentally reversed the measurement order of the
confext initrds and sysext initrds via a minor typo. This commit fixes
the typo and restores the original measurement order
Follow-up: ac32323
The proposal in https://github.com/systemd/systemd/pull/35091 suggests
that there are going to be more resources sooner or later that shall be
embeddable in a UKI, but are specific to some machine. The .hwids logic
as it is implemented right now is conceptually flexible enough to cover
that too (as long as the system has SMBIOS and thus CHIDs). Hence, let's
prepare the ground for a future (that might possibly never come, but
let's keep the door open) where the section can be reused for this
purpose.
The patch is really dumb ultimately. it just changes the initial field
in the "Device" struct to carry not just the size of it (as before) but
also a type indicator, that is for now fixed to 1, indicating DT blobs.
This breaks compatibility, hence this should get merged before we do the
v257 release, so that this is done properly before the first release
with .hwids.
Yu Watanabe
Lennart Poettering
nkraetzschmar
Ani Sinha
Daan De Meyer
Luca Boccassi
Antonio Alvarez Feijoo
anonymix007
Samuel Dionne-Riel
Zbigniew Jędrzejewski-Szmek
Adrian Vovk