Allow callers to pass NULL for ret_data and/or ret_size when they only
need to check whether a field exists. Initialize provided output
pointers to safe defaults and update the manual page accordingly.
Propagate the NULL-ness through to journal_file_data_payload() so that
downstream helpers can optimize for the existence-check case.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
There's no way to configure the log level for swtpm_setup, so pipe
it's logfile (which defaults to stderr) to /dev/null unless debug
logging is enabled.
Older swtpm versions print --help output instead of JSON when
swtpm_setup --print-profiles is invoked. Previously, the JSON parse
failure was treated as fatal, preventing swtpm manufacture entirely on
these older versions.
Extract profile detection into a separate swtpm_find_best_profile()
helper and treat JSON parse failure as a graceful fallback: log a
notice and continue without a profile, same as when no builtin profiles
are found.
Previously, probe_gpt_sector_size_mismatch() would bail out early when
the GPT sector size matched the device sector size. However, some
devices (e.g. certain CD-ROM drives) do not support kernel partition
scanning even when sector sizes match. In that case, the kernel still
cannot parse the partition table, and we need to set up a loop device to
expose the partitions — just as we do for the sector size mismatch case.
Check blockdev_partscan_enabled() when sector sizes match, and only skip
the boot partition check if partition scanning is actually supported.
Also rename the function, udev property, and log messages to reflect the
broader scope:
- probe_gpt_sector_size_mismatch() -> probe_gpt_boot_disk_needs_loop()
- ID_PART_GPT_AUTO_ROOT_DISK_SECTOR_SIZE_MISMATCH ->
ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP
Per UEFI specification §13.3.2, El Torito partition discovery applies to
any block device, not just optical media. Rename
disk_get_part_uuid_cdrom() to disk_get_part_uuid_eltorito() and update
all log messages and comments to say "El Torito" instead of "CDROM" to
reflect this.
Previously, probe_gpt_sector_size_mismatch() would bail out early when
the GPT sector size matched the device sector size. However, some
devices (e.g. certain CD-ROM drives) do not support kernel partition
scanning even when sector sizes match. In that case, the kernel still
cannot parse the partition table, and we need to set up a loop device to
expose the partitions — just as we do for the sector size mismatch case.
Check blockdev_partscan_enabled() when sector sizes match, and only skip
the boot partition check if partition scanning is actually supported.
Also rename the function, udev property, and log messages to reflect the
broader scope:
- probe_gpt_sector_size_mismatch() -> probe_gpt_boot_disk_needs_loop()
- ID_PART_GPT_AUTO_ROOT_DISK_SECTOR_SIZE_MISMATCH -> ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP
We have this rule in systemd that unless we are sure that getenv() is
safe and there's a reason to use it we should always prefer
secure_getenv(). Follow our own rules here, as per CODING_STYLE
document.
This really doesn't matter here, all of this is highly privileged, but
hopefully Claude & Colleagues shut up about this then, and maybe detect
the pattern better.
When the GPT partition table uses a different sector size than the
device's native block size (e.g. 512-byte GPT on a 2048-byte CD-ROM
booted via El Torito), the kernel cannot parse the partition table.
Probe the GPT sector size upfront and configure blkid with the correct
value so it always finds the partition table. If a sector size mismatch
is detected, trigger a loop device to re-expose the device with the
correct sector size and skip root partition discovery on the original
device — it will happen on the loop device instead.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
When a udev rule uses ENV{SYSTEMD_WANTS}+="systemd-loop@.service" on a
block device, the %f specifier in the service file resolves to the sysfs
path rather than the device node path. Detect sysfs paths in
parse_image_path_argument() and resolve them to the corresponding
devnode using sd_device_new_from_syspath() + sd_device_get_devname().
When booting from a CD-ROM via El Torito, the UEFI device path contains a
CDROM_DEVICE_PATH node instead of a HARDDRIVE_DEVICE_PATH node. Unlike the
hard drive variant, the CDROM node does not carry a partition UUID, so
systemd-boot previously could not determine the boot partition UUID in this
scenario.
Add disk_get_part_uuid_cdrom() which recovers the partition UUID by reading
the GPT from the underlying disk. Since ISO images are commonly mastered
with 512-byte GPT sectors on media with 2048-byte blocks, the function
probes for the GPT header at multiple sector sizes (512, 1024, 2048, 4096)
and matches the partition by comparing byte offsets between the CDROM node's
PartitionStart and each GPT entry's StartingLBA.
The function reuses read_gpt_entries() for GPT parsing and adds debug
logging for each failure path to aid diagnosis on real hardware.
Also adds the CDROM_DEVICE_PATH struct and MEDIA_CDROM_DP subtype constant
to device-path.h, and fixes disk_get_part_uuid() to preserve the original
device path pointer so it can be passed to the CDROM fallback.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
EFI_DISK_IO_PROTOCOL (UEFI spec section 13.7,
https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#disk-i-o-protocol)
supports reads at arbitrary byte offsets with no alignment requirements on the
buffer. The UEFI spec mandates that firmware produces this protocol on every
handle that also has EFI_BLOCK_IO_PROTOCOL, so it is always available.
This is a better fit than EFI_BLOCK_IO_PROTOCOL for our GPT parsing and
BitLocker detection because Block I/O requires that both the read offset (LBA)
and the buffer are aligned to the media's IoAlign value. Meeting that
constraint forces us to use xmalloc_aligned_pages() with
PHYSICAL_ADDRESS_TO_POINTER(), page-granularity allocations, and manual size
rounding (ALIGN_TO). Disk I/O handles all of that internally, so callers can
use plain xmalloc() or even stack buffers and read exactly the number of bytes
they need.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
Writing the El Torito boot catalog should be independent of writing the
partition table. Previously, the El Torito logic was embedded in
context_write_partition_table(), which meant it was skipped when the
partition table hadn't changed. Extract it into a separate
context_eltorito() function and invoke it after
context_write_partition_table() so the boot catalog is always written
when enabled.
Also move the overlap verification to be done as soon as we have all
the necessary information to do the check and before doing any expensive
work;
TEST-74-AUX-UTILS has a number of subtests.
test/units/TEST-74-AUX-UTILS.capsule.sh runs first and starts and stops
capsule@foobar.service. Looking at the test, the unit is cleanly stopped.
But later test/units/TEST-74-AUX-UTILS.machine-id-setup.sh tests for
failed units. capsule@foobar.service is listed as failed, causing the
second subtest to fail.
Add the same test in test/units/TEST-74-AUX-UTILS.capsule.sh to see
if the failed test really originates from there.
When systemd-cryptenroll --tpm2-device=auto is called on a system where
a tpm2-pcr-public-key.pem exists it automatically creates tokens with a
signed PCR policy. Unlocking such a token via --unlock-tpm2-device=auto
requires a tpm2-pcr-signature.json file, which is not present.
This creates a race with systemd-tpm2-setup.service at boot: if the
service completes before the test, the key exists and the subsequent
--unlock-tpm2-device=auto calls fail, which I believe is the cause of
the test flakiness.
This also seems to mesh with the fact that this only flakes on Debian
CI, since that's built with ukify which installs a public key.
Let's hopefully fix this by passing --tpm2-public-key= to all
--tpm2-device= enrollment calls that aren't explicitly intended to test
signed PCR policy behaviour.
the ISO9660 date range and the "struct tm" range are quite different,
let's add extra paranoia checks that we can always convert the dates
without issues or fail cleanly.
When systemd-cryptenroll --tpm2-device=auto is called on a system where
a tpm2-pcr-public-key.pem exists it automatically creates tokens with a
signed PCR policy. Unlocking such a token via --unlock-tpm2-device=auto
requires a tpm2-pcr-signature.json file, which is not present.
This creates a race with systemd-tpm2-setup.service at boot: if the
service completes before the test, the key exists and the subsequent
--unlock-tpm2-device=auto calls fail, which I believe is the cause of
the test flakiness.
This also seems to mesh with the fact that this only flakes on Debian
CI, since that's built with ukify which installs a public key.
Let's hopefully fix this by passing --tpm2-public-key= to all
--tpm2-device= enrollment calls that aren't explicitly intended to test
signed PCR policy behaviour.
This is a followup to https://github.com/systemd/systemd/pull/41400 with
the final set of tweaks so that the new coccinelle `check-pinters-deref`
checker runs without failures.
It also includes a commit with some fixes for redundant asserts and the
final commit to make the assert() in the inner loop of qsort
POINTER_MAY_BE_NULL which will become a no-op - that is probably the
most controversial one, I hope the commit message explains the
trade-offs, I'm happy to drop it, I have no strong opinion either way.
Please see the individual commits/commit messages for more details, most
is (hopefully) relatively boring/mechanical.
Verify that GPT images with an ISO9660 El Torito boot catalog are
dissected via the GPT partition table rather than being treated as a
single iso9660 filesystem.
Follow-up for e33eb053fb ("dissect-image: Drop
blkid_probe_filter_superblocks_usage() call from probe_blkid_filter()")
probe_blkid_filter() sets up a blkid superblock filter to restrict
filesystem detection to a known-safe set of types (btrfs, erofs, ext4,
f2fs, squashfs, vfat, xfs). It does so via two consecutive calls:
1. blkid_probe_filter_superblocks_type(BLKID_FLTR_ONLYIN, ...)
2. blkid_probe_filter_superblocks_usage(BLKID_FLTR_NOTIN, BLKID_USAGE_RAID)
However, both filter functions share the same internal bitmap in libblkid.
Each call goes through blkid_probe_get_filter(), which zeroes the entire
bitmap before applying the new filter. This means the second call (usage
filter) silently destroys the type filter set by the first call.
The result is that only RAID superblocks end up being filtered, while all
other filesystem types — including iso9660 — pass through unfiltered.
This causes ISO images (e.g. those with El Torito boot catalogs and GPT)
to be incorrectly dissected: blkid detects the iso9660 superblock on
the whole device (since iso9660 is marked BLKID_IDINFO_TOLERANT and can
coexist with partition tables), the code enters the unpartitioned
single-filesystem path, and then mounting fails because iso9660 is not
in the allowed filesystem list:
"File system type 'iso9660' is not allowed to be mounted as result
of automatic dissection."
Fix this by dropping the blkid_probe_filter_superblocks_usage() call.
The BLKID_FLTR_ONLYIN type filter already restricts probing to only
the listed types, which implicitly excludes RAID superblocks as well,
making the usage filter redundant.
Follow-up for 72bf86663c ("dissect: use blkid_probe filters to restrict
probing to supported FSes and no raid")
allowed_fstypes() returns the list of filesystem types that we are
willing to mount. However, the blkid probe filter needs to detect
additional non-mountable types: crypto_LUKS (so that LUKS-encrypted
partitions can be identified and decrypted) and swap (so that swap
partitions can be identified).
Without these types in the BLKID_FLTR_ONLYIN filter, blkid reports
"No type detected" for encrypted and swap partitions, causing
image policy checks to fail (e.g. "encrypted was required") and
mount operations to fail with "File system type not supported".
Note that verity types (DM_verity_hash, verity_hash_signature) do
not need to be added here because their fstype is assigned directly
during partition table parsing, not via blkid probing.
Follow-up for e33eb053fb.
Add --cxl=BOOL option to enable CXL (Compute Express Link) support in
the virtual machine. CXL is a high-speed interconnect standard that
allows CPUs to access memory attached to devices such as accelerators
and memory expanders, enabling flexible memory pooling and expansion
beyond what is physically installed on the motherboard. When enabled,
adds cxl=on to the QEMU machine configuration. Only supported on x86_64
and aarch64 architectures.
This is added for testing purposes and for feature parity with mkosi's
CXL= setting.
Extend --ram= to accept an optional maximum size for memory hotplug,
using the syntax --ram=SIZE[:MAXSIZE] (e.g. --ram=2G:8G). When a
maximum is specified, the maxmem key is added to the QEMU memory
configuration section to enable memory hotplug up to the given limit.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
If a unit has FileDescriptorStorePreserve=yes we'll keep its FDs around
in case it starts again. But if there are no reverse dependencies
referencing it, we'll also GC it and lose all the FDs, which defeats the
point of the setting (which is opt-in).
Do not GC units that have FDs stored to avoid this.
Follow-up for b9c1883a9c
When running `updatectl update` since f0b2ea63, Install() was called
with the version resolved by Acquire() rather than the originally
requested (empty) version, causing the stricter update-to-version polkit
action to be used instead of the update polkit action.
noxiouz
Daan De Meyer
Luan Vitor Simião oliveira
Christian Brauner
Lennart Poettering
David Santamaría Rogado
Zbigniew Jędrzejewski-Szmek
Chris Down
Luca Boccassi
Marek Adamski
Balázs Meskó
Zbigniew Jędrzejewski-Szmek
Clayton Craft
