sd-resolved does dnssec "backwards" compared to most resolvers.
A typical strategy is to start from the DNS root and gather the
requisite keys on the way down, but sd-resolved requests the final
answer it wants and then goes searching for the requisite keys later.
We don't know in advance under which names we should expect to find
those keys, because we don't know the zone cuts a priori, but we can use
what we have found in prior responses to make an educated guess. This
was more or less the intent of 47690634f1, but it was partially
regressed in d840783db5 while fixing a bug handling totally empty
responses.
Fixes#37472
Ref: 47690634f1 ("resolved: don't request the SOA for every dns label")
Fixes: d840783db5 ("resolved: always progress DS queries")
Commit 0e1ede4b4b introduced a bug where
we'd always fetch the "original" (empty) list of groups when processing
a comma-separated list of groups from the --member-of= option, so only
the last group from the list would get applied. This bug was then later
(in 316e9887f2) refactored into a separate
function.
Follow-up for 0e1ede4b4b.
Resolves: #41286
sd-resolved does not support all the permissible DNSSEC signature
algorithms, and some are intentionally unsupported as a matter of
policy. Answers that can only be validated via unsupported algorithms
should be treated as if they were unsigned, per RFC4035 § 5.2.
Previously, sd-resolved tried to properly record insecure answers for
unsupported algortihms, but did not record this status for each of the
auxilliary DNSSEC transactions, so the primary transaction had no way to
know if there was a plausible DNSKEY with an unsupported signature
algorithm in the chain of trust.
This commit adds the insecure DNSKEYs that use unsupported algorithms to
the list of validated keys for each transaction, so that dependent
transactions can learn that a plausible chain of trust exists, even if
no authenticated one does, and report the insecure answer.
This should improve the situation in #35126.
vmspawn previously hardcoded virtio-blk for all drives. This adds
--image-disk-type= to select the root disk type (virtio-blk,
virtio-scsi, or nvme) and allows per-drive overrides via a
colon-separated prefix on --extra-drive=. The format and disk type
prefixes can appear in any order since their value sets don't overlap.
For virtio-scsi, a single shared controller is created with drives
attached as scsi-hd devices. For nvme, each drive gets its own
controller. Both have serial number length limits (30 and 20 characters
respectively), so long filenames are replaced with a truncated SHA-256
hex digest.
This is an extension of the /etc/hosts concept, but can provide any kind
of RRs (well, actually, we only parse A/AAAA/PTR for now, but the
concept is open for more).
Fixes: #17791
When we are told to reload our configuration also flush out /etc/hosts
explicitly. This is particularly relevant since we suppress too frequent
reloads, and hence a synchronous way to force a reload is very useful.
This is almost the same as inode_hash_ops, but also hashes + compares
all attributes that could affect the contents of a file. It ignores
"superficial"/"external" attributes such as ownership or access mode
however.
This doesn't really have any major benefit, but it does make this nicely
mirror stat_inode_same() which also checks this triplet for identifying
identical inodes.
Extend --image-disk-type= and the --extra-drive= disk type prefix to
support nvme in addition to virtio-blk and virtio-scsi:
systemd-vmspawn --image-disk-type=nvme --image=image.raw
systemd-vmspawn --image=image.raw --extra-drive=nvme:data.raw
The NVMe serial number is limited to 20 characters by the NVMe spec.
If the image filename exceeds this, it is hashed with SHA-256 and
truncated to 20 hex characters via the disk_serial() helper introduced
in the previous commit.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add --image-disk-type= to select the disk type for the root disk, and
allow specifying the disk type as a colon-separated prefix on
--extra-drive=:
systemd-vmspawn --image-disk-type=virtio-scsi --image=image.raw
systemd-vmspawn --image=image.raw --extra-drive=virtio-scsi:data.raw
For --extra-drive=, the format and disk type prefixes can appear in any
order since the value sets don't overlap:
--extra-drive=raw:virtio-scsi:/path
--extra-drive=virtio-scsi:raw:/path
Extra drives inherit --image-disk-type= by default unless overridden
with an explicit prefix.
vmspawn originally used virtio-scsi for all drives but switched to
virtio-blk in 1f24a954e4 for simplicity and direct kernel boot
compatibility. This makes virtio-scsi available again as an explicit
option for cases where a SCSI storage topology is desired.
For virtio-scsi, a shared virtio-scsi-pci controller is created and
drives are attached as scsi-hd devices. The SCSI serial number is
limited to 30 characters, so filenames exceeding this are hashed with
SHA-256.
Signed-off-by: Christian Brauner <brauner@kernel.org>
It's unclear why I added this in fd05c6c759,
but it breaks bind mounting regular directories via --bind,
so drop it again since it's not actually required to make virtiofsd
work with the foreign UID range.
Just in case, ensure the sha256 that is used as a symmetric
key for encrypted creds is safely erased from memory.
Reported on yeswehack.com as YWH-PGM9780-166
Follow-up for 21bc0b6fa1
This is an another alternative for #40656, based on @poettering's
suggestion to use an ELF section.
The output of --help is generated using format-table, but the details of
the formatting a bit off: different sections in the table (verbs, option
groups) are not aligned to the same column. Our current table formatting
doesn't make this easy. If somebody has an idea how to do this without
too much pain, please make suggestions.
Another thing that I didn't know how to do nicely, was to use the two
columns of separation. But maybe this doesn't matter. If we switch to
one column everywhere, I don't think people will care.
Example output:
```console
$ build/systemd-id128 -h | cat
systemd-id128 [OPTIONS...] COMMAND
Generate and print 128-bit identifiers.
Commands:
new Generate a new ID
machine-id Print the ID of current machine
boot-id Print the ID of current boot
invocation-id Print the ID of current invocation
var-partition-uuid Print the UUID for the /var/ partition
show [NAME|UUID] Print one or more UUIDs
help Show this help
Options:
-h --help Show this help
--version Show package version
--no-pager Do not start a pager
--no-legend Do not show headers and footers
--json=FORMAT Output inspection data in JSON (takes one of pretty,
short, off)
-j Equivalent to --json=pretty (on TTY) or --json=short
(otherwise)
-p --pretty Generate samples of program code
-P --value Only print the value
-a --app-specific=ID Generate app-specific IDs
-u --uuid Output in UUID format
See the systemd-id128(1) man page for details.
```
The output wraps automatically with terminal width. If the terminal is
extremely narrow, ellipsization occurs. I think this doesn't matter
and/or is actually a feature. Such narrow terminals mostly occur in
testing, so it doesn't matter what exactly we do, as long as it is
something somewhat reasonable.
Anyway, I think this is enough as PoC. Please compare this with the
previous approach. /cc @behrmann, @YHNdnzj, @poettering
The three binaries that are converted have options, verbs, optional
arguments, and options terminate option parsing, so most of the
functionality is there. One thing that I didn't implement that was
present in previous PRs is "namespaces", i.e. multiple parsers in the
same source file. I expect that we can handle this similarly to option
groups.
sd-resolved does not support all the permissible DNSSEC signature
algorithms, and some are intentionally unsupported as a matter of
policy. Answers that can only be validated via unsupported algorithms
should be treated as if they were unsigned, per RFC4035§5.2.
Previously, sd-resolved tried to properly record insecure answers for
unsupported algortihms, but did not record this status for each of the
auxilliary DNSSEC transactions, so the primary transaction had no way to
know if there was a plausible DNSKEY with an unsupported signature
algorithm in the chain of trust.
This commit adds the insecure DNSKEYs that use unsupported algorithms to
the list of validated keys for each transaction, so that dependent
transactions can learn that a plausible chain of trust exists, even if
no authenticated one does, and report the insecure answer.
Old gcc (<14) says:
2026-03-02T23:11:28.5676353Z In file included from ../src/notify/notify.c:30:
2026-03-02T23:11:28.5694607Z In function ‘strv_isempty’,
2026-03-02T23:11:28.5695481Z inlined from ‘action_fork’ at ../src/notify/notify.c:440:9,
2026-03-02T23:11:28.5696266Z inlined from ‘run’ at ../src/notify/notify.c:541:24,
2026-03-02T23:11:28.5696929Z inlined from ‘main’ at ../src/notify/notify.c:682:1:
2026-03-02T23:11:28.5697877Z ../src/basic/strv.h:108:23: error: ‘args’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-03-02T23:11:28.5698655Z 108 | return !l || !*l;
2026-03-02T23:11:28.5699052Z | ^~
2026-03-02T23:11:28.5700020Z ../src/notify/notify.c: In function ‘main’:
2026-03-02T23:11:28.5700681Z ../src/notify/notify.c:531:16: note: ‘args’ was declared here
2026-03-02T23:11:28.5701217Z 531 | char **args;
2026-03-02T23:11:28.5701574Z | ^~~~
2026-03-02T23:11:28.5701960Z cc1: all warnings being treated as errors
This feel a bit like a hack, but it works OK. The width of the first
column of verbs or options in different sections is measured and
applied to the other tables. This makes the second column aligned.
networkctl previously called networkd over D-Bus for several operations.
This replaces all of those calls with Varlink, making it the sole IPC
mechanism between networkctl and networkd.
New Varlink methods added to networkd:
- io.systemd.Network.Link (new sub-interface for link-specific
operations):
- Link.Describe — replaces Link.BitRates + DHCPServer.Leases D-Bus
properties
- Link.Up — replaces Link.SetUp D-Bus method (moved from
**io.systemd.Network.LinkUp**)
- Link.Down — replaces Link.SetDown D-Bus method (moved from
**io.systemd.Network.LinkDown**)
- Link.Renew — replaces Link.Renew D-Bus method
- Link.ForceRenew — replaces Link.ForceRenew D-Bus method
- Link.Reconfigure — replaces Link.Reconfigure D-Bus method
- io.systemd.service
- Reload — replaces Manager.Reload D-Bus method
Supporting changes:
- link_get_bit_rates() extracted from networkd-link.c into
networkd-speed-meter.c
- BitRates added to link_build_json() so Link.Describe returns them
inline
alongside the existing interface description, replacing a separate D-Bus
read
- link_reconfigure_full() and manager_reload() extended to accept
sd_varlink*
for deferred async replies (consistent with existing sd_bus_message*
path)
- DHCP lease display (networkctl status) uses Link.Describe instead of
DHCPServer.Leases; falls back to ClientId when hostname is not present
This is not actually used so it doesn't really matter in
practice and the fields are used anyway, but for cleanliness
fix it
Reported on yeswehack.com as YWH-PGM9780-165
Follow-up for 5699a1689b
systemd now has a system call wrapper that does a long series of #ifdef's to
differentiate between architectures and ABIs. This wrapper has two problems.
1. On mips, it needs to differentiate between O32, N32, N64 ABI. It does that
via a code block in src/include/override/sys/generate-syscall.py (and derived
files):
76 # elif defined(_MIPS_SIM)
77 # if _MIPS_SIM == _MIPS_SIM_ABI32
78 # define systemd_NR_{syscall} {nr_mipso32}
79 # elif _MIPS_SIM == _MIPS_SIM_NABI32
80 # define systemd_NR_{syscall} {nr_mips64n32}
81 # elif _MIPS_SIM == _MIPS_SIM_ABI64
82 # define systemd_NR_{syscall} {nr_mips64}
83 # else
84 # error "Unknown MIPS ABI"
85 # endif
86 # elif defined(__hppa__)
Now the _MIPS_SIM* constants stem from a vendor-specific header file sgidefs.h,
which is included with glibc, but not with musl. It is however always present
in the Linux kernel headers as asm/sgidefs.h ...
2. To work around this, the syscall wrapper already has a block
47 #ifdef ARCH_MIPS
48 #include <asm/sgidefs.h>
49 #endif
Turns out, ARCH_MIPS is defined nowhere in Gentoo, neither on glibc nor on musl.
As a result the code (by accident, probably sgidefs.h is included transitively
somehow) works on glibc, but not on musl.
The simplest fix is to replace line 47 in the generator and the derived file
with
47 #ifdef __mips__
Two other source code files require a similar fix since they rely on the
constants.
Bug: https://github.com/systemd/systemd/issues/41239
Bug: https://bugs.gentoo.org/971376
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
The commit 6d7cb9a6b8 fixes the assignment
of the these options when specified through SendOption=. However, it
breaks when specified through UserClass= or SendVendorOption=.
When UserClass= or SendVendorOption= is specified, the option length is
calculated from the sd_dhcp_client.user_class or .vendor_options. Hence,
we can use 0 for the length in that case.
Follow-up for 6d7cb9a6b8.
clang says:
src/dissect/dissect.c:292:17: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
Another option would be to raise the C standard to C23. I think that'd
make sense, but it's better to do it separately.
Some cosmetic differences in descriptions are made.
--quiet was miscategorized as a command (172fadda65),
--usr-hash and --usr-hash-sig were not listed (10b8d65f3f).
The behaviour that was implemented in systemd-dissect was that
both '--exec -- cmd' and '--exec cmd' result in 'cmd' as the command,
and '--' anywhere later is as a positional argument, so nesting is
possible, e.g.:
--exec -- cmd --opt -- another-cmd --another-opt
This is not obvious, so add some tests for this and keep it as a separate
commit.
Add tests for OPTION_STOPS_PARSING, OPTION_GROUP_MARKER, and
OPTION_OPTIONAL_ARG flags with manual Option arrays, and a separate
test exercising the OPTION, OPTION_LONG, OPTION_SHORT, OPTION_FULL,
and OPTION_GROUP macros via FOREACH_OPTION_FULL in a switch statement,
as they would be used in real code.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit allows unset pidref when calling manager_log_caller().
With that we can log manager calls even if we cannot resolve the
caller. Currently when we cannot resolve the caller we are just
not logging anything. With this commit we at least log the call
(even though we don't know what caller it was).
Thanks to keszybz for the suggestion.
Ronan Pigott
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Daan De Meyer
Christian Brauner
Luca Boccassi
Yu Watanabe
Andreas K. Hüttel
Michael Vogt