Reproducer:
unit=run-nb-trigger-$(date +%s)
systemd-run --no-block --collect --unit="$unit" \
--socket-property=ListenStream=/proc/systemd-run-repro/socket \
/usr/bin/true
echo $?
Before, systemd-run still waited for the trigger unit job and
propagated the socket start failure. With --no-block it should only
verify and enqueue the request, as the service path already does.
Follow-up for 3d161f991e
Let's optimize userdb queries a bit: by encoding the covered UID/GID
ranges and user/group name patterns on the varlink entrypoint sockets
for userdb backends we can make them wake up less and reduce the work
triggered by queries.
Treat an empty volume name alongside other fields as unset instead of
rejecting it as invalid.
Example use case:
```
EncryptedVolume=:none:discard
```
In this case, the volume name is not specified so it can be generated as
luks-UUID.
From the docs:
> EncryptedVolume=
> Specifies how the encrypted partition should be set up. Takes at least
one and at most four fields separated with a colon (":"). The first
field specifies the encrypted volume name under /dev/mapper/. If not
specified, "luks-UUID" will be used where "UUID" is the LUKS UUID.
prctl() is an API full of pitfalls: it is variadic, and some interfaces
don't expect zero-initialization of excess arguments, and others do.
Moreover, the parameters are "long", and nonetheless we usually pass
"int" to them. If we are too dumb to call it properly, let's just not
call it directly anymore, but let's add a wrapper around it that makes
the function non-variadic and declares the right types. Then, let's port
over everything to it.
This is inspired by #42996, but we had issues with this many times,
before and looking at this PR one can see that we otherwise still are
having the issue at numerous other places.
The current TPM2 PIN mode is flawed as a compromised TPM directly
exposes
the sealed secret which is the LUKS volume key itself
(https://github.com/systemd/systemd/pull/27502 and
https://github.com/systemd/systemd/issues/37386).
Goal: add Argon2id-based PIN hardening to TPM2 enrollment, making
the TPM a second factor rather than a single point of failure:
1. Password + salt → Argon2id → 512-bit key split into Key1 + Key2
2. Key2 (base64-encoded) is used as the PIN to seal a random secret
in the TPM
3. Key1 + unsealed secret → HKDF-SHA256 → final LUKS volume key
This implementation ensures that if the TPM is compromised, an attacker
still needs the password to derive Key1 and combine it with the unsealed
secret.
The --tpm2-with-pin= option now accepts three values:
- false (no PIN used)
- true (PIN hardened with Argon2id - default)
- "direct" (legacy PIN without Argon2id for backward compatibility)
Argon2id parameters are customizable via:
--tpm2-argon2id-memory=
--tpm2-argon2id-iterations=
--tpm2-argon2id-parallelism=
--tpm2-argon2id-iter-time=
These default to a function of available CPUs and physical memory, with
a benchmark that scales iterations to the target time (default: 2s) and
falls back to ARGON2ID_PARAMETERS_DEFAULT (64 MiB, 8 iter, 4 lanes) when
auto detection fails.
Also if the runtime OpenSSL lacks Argon2id support (< 3.2), the feature
silently falls back to direct PIN mode with a warning.
Added includes:
- src/cryptenroll/cryptenroll.c: cpu-set-util.h, limits-util.h,
time-util.h
for Argon2id benchmark auto-tuning (cpus_online, physical_memory_scale,
now/usec_t)
- src/cryptenroll/cryptenroll-tpm2.c: crypto-util.h for
Argon2IdParameters
struct in load_volume_key_tpm2()
- src/shared/tpm2-util.h: crypto-util.h for Argon2IdParameters in
tpm2_make_luks2_json() API
- src/cryptsetup/cryptsetup-tokens/luks2-tpm2.c: crypto-util.h for
kdf_argon2id_derive()/kdf_hkdf_sha256() on the token unlock path
This adds similar concepts as we already have for enable-component:
let's add a way to enable all features or the suggeste dones, and
possibly on all components.
Or in other words, with this:
systemd-sysupdate enable-component -S
systemd-sysupdate enable-feature -A -s
We'll automatically enable all suggested components, and all features of
them.
Let's now introduce "systemd-sysupdate enable-component
--component-suggested" and systemd-sysupdate enable-component
--component-all" for enabling all or all suggested components at once.
Similar, if used for disable-component will disable all components or
those not suggested.
While --component-all really picks all components --component-suggested
picks only the suggested ones.
Note that none of the verbs currently implement the concept, they will
all refuse the option. Hooking this up is going to be added next.
Let's make it possible to "suggest" that certain features or components
are enabled under some conditions.
For this, both features and components gain two things:
1. A Suggested= field which takes a boolean. If true the
feature/component will be suggested for installation, if false it
will not.
2. A set of SuggestedOnXYZ= settings are modelled after ConditionXYZ= in
unit files (and implement a subset of them), will suggest some
component/feature under specific conditions.
The result of the condition is shown in the various output tools.
There's an edge case where a single-shot timer using WakeSystem=yes
could get re-armed after elapsing. For example, when a timer is created
using:
$ systemd-run --user --on-active="1m" --timer-property=WakeSystem=yes flatpak run io.bassi.Amberol
and the system is then suspended, following sequence of events may
happen:
Jul 08 06:57:25 systemd[2640]: run-p192456-i199160.timer: Installed new job run-p192456-i199160.timer/start as 7675
Jul 08 06:57:25 systemd[2640]: run-p192456-i199160.timer: Enqueued job run-p192456-i199160.timer/start as 7675
Jul 08 06:57:25 systemd[2640]: run-p192456-i199160.timer: Monotonic timer elapses in 59.999999s.
Jul 08 06:57:25 systemd[2640]: run-p192456-i199160.timer: Changed dead -> waiting
Jul 08 06:57:25 systemd[2640]: run-p192456-i199160.timer: Job 7675 run-p192456-i199160.timer/start finished, result=done
Jul 08 06:57:25 systemd[2640]: Started [systemd-run] /usr/bin/flatpak run io.bassi.Amberol.
Jul 08 06:58:13 systemd[2640]: run-p192456-i199160.timer: Time change, recalculating next elapse.
Jul 08 06:58:13 systemd[2640]: run-p192456-i199160.timer: Monotonic timer elapses in 12.785674s.
Jul 08 06:58:26 systemd[2640]: run-p192456-i199160.timer: Timer elapsed.
Jul 08 06:58:26 systemd[2640]: run-p192456-i199160.timer: Changed waiting -> running
Jul 08 06:58:29 systemd[2640]: run-p192456-i199160.timer: Got notified about unit deactivation.
Jul 08 06:58:29 systemd[2640]: run-p192456-i199160.timer: Monotonic timer elapses in 33.544681s.
Jul 08 06:58:29 systemd[2640]: run-p192456-i199160.timer: Changed running -> waiting
Jul 08 06:59:48 systemd[2640]: run-p192456-i199160.timer: Timer elapsed.
1) The timer is armed at 06:57:25. timer_enter_waiting()
calculates following values:
base = M0 (current CLOCK_MONOTONIC)
usec_shift_clock(base, CLOCK_MONOTONIC, CLOCK_BOOTTIME_ALARM) = M0 (no delta yet)
v->next_elapse = M0 + 60s
The timer is on CLOCK_BOOTTIME_ALARM at M0 + 60s
2) System suspends. If the system ran for ~12s and was suspended for
~36s, at resume we'd get:
CLOCK_MONOTONIC = M0 + 12s
CLOCK_BOOTTIME = M0 + 12s + 36s = M0 + 48s
3) timer_time_change() fires and calls timer_enter_waiting(t, true)
Because time_change=true, v->next_elapse is not recalculated and
keeps the original M0 + 60s value. The timer then correctly computes
the remaining time as ~12.8 seconds:
Jul 08 06:58:13 ...: Monotonic timer elapses in 12.785674s.
4) Timer elapses at 06:58:26
Jul 08 06:58:26 ...: Timer elapsed.
timer_enter_running() sets last_trigger.monotonic to CLOCK_MONOTONIC
(which equals to M0 + 12s before suspend + 13s after suspend, thus
+ 25s)
5) Unit deactivates at 06:58:29
timer_trigger_notify() calls timer_enter_waiting(t, false) -
time_change=false; that means that this time v->next_elapse gets
recalculated:
base = inactive_exit_timestamp.monotonic = M0 (i.e. when the timer was originally armed)
usec_shift_clock(M0, CLOCK_MONOTONIC, CLOCK_BOOTTIME_ALARM)
a = now(CLOCK_MONOTONIC) = M0 + 28s
b = now(CLOCK_BOOTTIME_ALARM) = M0 + 64s
result = b - (a - M0) = (M0 + 64s) - 28s = M0 + 36s => the time spent in suspend
Hence v->next_elapse = (M0 + 36s) + 60s = M0 + 96s
This then skips disabling of one-shot timers in the following check,
because the expression
v->next_elapse < triple_timestamp_by_clock(&ts, TIMER_MONOTONIC_CLOCK(t))
is false, because the v->next_elapse (M0 + 96s) is not less than the
current time (M0 + 64s), so the timer is re-armed again:
Jul 08 06:58:29 ...: Monotonic timer elapses in 33.544681s
Let's mitigate this by skipping the next elapse timestamp recalculations
for one-shot timers for which we've already calculated the value in this
activation cycle.
Resolves: #42929
SImilar reasons as for the memfd change: let's normalize behaviour and
always use pid_get_comm().
This adds escaping here for the first time, which is a good thing.
Let's the common function for querying the local thread name.
This changes the escaping rules when the therad name is not quite
kosher: previously we'd just escape invalid UTF-8 charcaters, now we do
what we usually do: also escape control characters and such, and limit
us to ASCII.
The description generated here is mostly for debug purposes, and process
names should normally not require this escaping anyway (it's mostly
paranoia), hence I think this change in behaviour should be fine, it's
not part of the API in any form.
With 2c6f9af8e5 sd-varlink gained protocol
upgrade support, however only in a synchronous fashion. This adds
asynchronous protocol upgrade for the server side, thus enabling
multiplexing daemons (i.e. those that handle multiple connections from
the same event loop) to support protocol upgrades too.
I plan to use this in the upcoming "ptybroker" component that allows
acquiring a pty through varlink.
/cc @mvo5
Currently, --copy-from= copies the paddings in between the source partitions,
as well as the trailing padding that is at the end of the source partition table.
It doesn't copy the leading padding at the start of the source partition table
though.
This seems inconsistent, and likely it was an oversight that the trailing padding
is copied.
Fix that, and add a test to ensure we don't regress.
The --copy-from= argument currently is documented as "copied partitions will have
the same size". This doesn't hold true in the case where a different grain-size is
passed to repart. Because `partition_min/max_size()` currently do rounding, the
size is implicitly rounded to grain size, and therefore partitions are enlarged
to align to grain size whenever possible.
Clarify this behavior and change the manpage, and also add a test for it.
This is a little bit confusing, but grain size is not actually stored in the gpt
metadata. Rather, fdisk's `get_grain_size()` returns an autodiscovered "optimal io
size" value as grain size. This might not actually be the grain size that the
disk we're copying is using.
Since we're setting the padding of the copied partitions using that value from
fdisk, we're rounding the new paddings by fdisk's optimal grain size, which is
usually 1MiB (a lot more then the default 4KiB that we're using otherwise).
Set the grain size here to 1 byte instead, ensuring that the min/max padding set
is exactly the padding that was present before.
Also add a test to confirm the behavior is fixed: The test calls --copy-from= on
an existing disk with 4MiB grain size, and because we pass --grain-size=512, now
no rounding should happen and the paddings should be transferred to exactly the
same size.
Return from argument parsing when --wait-daemon= cannot be parsed.
This matches the other timeout options.
Reproducer:
udevadm trigger --dry-run --wait-daemon=bad
Before:
Failed to parse timeout value 'bad', ignoring: Invalid argument
Follow-up:
2001622c58
Merge children_max from the per-source UdevConfig values before
defaulting it from system resources.
Reproducer:
systemd-udevd --debug --children-max=1
Before:
Set children_max to 32
Follow-up:
04fa5c1580
udevadm info rejects positional devices together with
--device-id-of-file=.
Document that behavior instead of saying positional arguments are
ignored.
Reproducer:
udevadm info --device-id-of-file=/etc/passwd /sys
Before:
Devices are not allowed with -d/--device-id-of-file and -c/--cleanup-db.
Follow-up:
31767b92a0
The settle command does not define positional arguments.
Reject them during argument parsing instead of silently ignoring
them.
Reproducer:
udevadm settle /no/such/argument
Before:
The command exits successfully and ignores the argument.
Follow-up:
c71509028f
The documentation says --initialized= is ignored when --removed is
specified.
Track --removed separately so it wins regardless of option order.
Reproducer:
udevadm wait --timeout=0 --removed --initialized=no /dev/no-such-test-device
Before:
Timed out for waiting devices being added.
Follow-up:
aa2b0d8d29
The --attr-match= and --attr-nomatch= filters are documented as
FILE[=VALUE], like the trigger filters.
Accept a bare attribute name for sysfs attribute presence matches.
Reproducer:
udevadm info --export-db --attr-match=ifindex
Before:
Expected <ATTR>=<value> instead of 'ifindex'
Follow-up:
a6b4b2fa01
When input_id prints a decoded capability bitmap, an all-zero
bitmap can decrement the index to zero.
Check the index before reading bitmask[val - 1].
Reproducer:
udevadm test-builtin input_id with an all-zero capability mask
Follow-up:
912541b024
tpm2-util.h includes crypto-util.h, which requires OpenSSL compiler
flags when HAVE_OPENSSL is defined. Add libopenssl_cflags to every
build target that uses tpm2_cflags but was missing the transitive
OpenSSL dependency.
The current TPM2 PIN mode is flawed as a compromised TPM directly exposes
the sealed secret which is the LUKS volume key itself (#27502 and #37386).
Goal: add Argon2id-based PIN hardening to TPM2 enrollment, making
the TPM a second factor rather than a single point of failure:
1. Password + salt -> Argon2id -> 512-bit key split into Key1 + Key2
2. Key2 (base64-encoded) is used as the PIN to seal a random secret
in the TPM
3. Key1 + unsealed secret -> HKDF-SHA256 -> final LUKS volume key
This implementation ensures that if the TPM is compromised, an attacker
still needs the password to derive Key1 and combine it with the unsealed
secret.
The --tpm2-with-pin= option now accepts three values:
- false (no PIN used)
- true (PIN hardened with Argon2id - default)
- "direct" (legacy PIN without Argon2id for backward compatibility)
Argon2id parameters are customizable via:
--tpm2-argon2id-memory=
--tpm2-argon2id-iterations=
--tpm2-argon2id-parallelism=
--tpm2-argon2id-iter-time=
These default to a function of available CPUs and physical memory, with
a benchmark that scales iterations to the target time (default: 2s) and
falls back to ARGON2ID_PARAMETERS_DEFAULT (64 MiB, 8 iter, 4 lanes) when
auto detection fails.
Also if the runtime OpenSSL lacks Argon2id support (< 3.2), the feature
silently falls back to direct PIN mode with a warning.
Added includes:
- src/cryptenroll/cryptenroll.c: cpu-set-util.h, limits-util.h, time-util.h
for Argon2id benchmark auto-tuning (cpus_online, physical_memory_scale,
now/usec_t)
- src/cryptenroll/cryptenroll-tpm2.c: crypto-util.h for Argon2IdParameters
struct in load_volume_key_tpm2()
- src/shared/tpm2-util.h: crypto-util.h for Argon2IdParameters in
tpm2_make_luks2_json() API
- src/shared/tpm2-util.c: limits-util.h, tpm2-util.h for physical_memory() validation
of Argon2id memory cost and function prototypes
- src/cryptsetup/cryptsetup-tokens/luks2-tpm2.c: crypto-util.h for
kdf_argon2id_derive()/kdf_hkdf_sha256() on the token unlock path
We can't make a lot of restrictions here, since users are allowed to
basically freely pick their user names and UIDs too. But let's at least
exclude system UID ranges and those beyond the 16bit range.
When doing a userdb lookup we might end up issuing a lot of IPC calls in
parallel to backends and cause them all to do work, with us waiting for
it. Let's optimize this a bit, and indicate on the socket inodes via
xattrs hints which kind of records are provided by a backend. That way
we can suppress lookups to them and optimize runtime behaviour.
This only works on Linux 7.1 and newer where socket inodes gained
support for extended attributes.
This are to the existing sd_varlink_call_and_upgrade() what
sd_varlink_callb() and sd_varlink_callbo() are to sd_varlink_call():
they put together an object on the fly, via the usual JSON builder
logic.
dongshengyuan
Luca Boccassi
Lennart Poettering
Frantisek Sumsal
Jonas Dreßler
fuldeka
Hans de Goede