So far we expected the client to access the access mode themselves, and
set a restrictive 0700 server-side.
However, in some scenarios it's handy if the inode is created
server-side already with the right mode, in particular when the client
doesn't do anything with the dir just yet, and just needs it to be there
with the right mode. If it has to adjust the mode client-side it might
otherwise need to fork something off, join the selected userns, adjust
the mode, and kill the child off again.
Let's move this from user-record.c into generic code and let's beef it
up a bit: allow parsing octal strings. This is particular relevant given
json_variant_new_stat() generates the mode in that format, and we
probably should be able to parse our own fields (even though we
currently don't do that for the data from json_variant_new_stat()).
Now that sd-event doesn't insist on blocking
SIGCHLD anymore when watching for process exit,
let's stop blocking SIGCHLD tree-wide where not
required anymore.
Loading images is, generally speaking, the slowest part of sd-executor
when spawning a service. This is due to multiple factors. dm-verity is
obviously a big part of the cost, but dissecting in general via libblkid
also can take a lot of time, due to probing the images and their
filesystems.
A performance test doing service restarts in a row shows these
results, ran on a production system (low power and slow ARM64 SOC) with
a real production service, show the following service interruption
intervals:
```
Count | P50 (ms) | P90 (ms) | P95 (ms) | P99 (ms) | P99.9 (ms)
507 | 1,532 | 1,726 | 2,548 | 4,112 | 4,592
```
One iteration is 507 restarts in this case, but this has ran hundreds
of times and the results are always in line within margin of error.
This also holds true for metrics from live systems, same numbers.
Between 1.0s and 1.2s can be attributed by profiling to the time needed
for the service code itself to start up and sd_notify, the rest is spent
inside systemd's code.
This means there is currently a tradeoff for services - either use
secure
images, or make restarting fast. Downtime of services is a very
important
metric, as for many cases this directly translates to outages, total or
partial (blackouot or greyout).
In order to facilitate using secure images without downsides, skip the
slow dissect steps (probing, loop devices, etc) when the configured
image is a single filesystem dm-verity image with a policy that pins it
to a single filesystem, and an already existing and open dm-verity
device
can be found and reused.
This allows orchestrators to pre-open images on download, before
restarting
services, to minimize downtimes.
Loading images is, generally speaking, the slowest part of sd-executor
when spawning a service. This is due to multiple factors. dm-verity is
obviously a big part of the cost, but dissecting in general via libblkid
also can take a lot of time, due to probing the images and their filesystems.
A performance test doing service restarts in a row shows these
results, ran on a production system (low power and slow ARM64 SOC) with
a real production service, show the following service interruption intervals:
Count | P50 (ms) | P90 (ms) | P95 (ms) | P99 (ms) | P99.9 (ms)
507 | 1,532 | 1,726 | 2,548 | 4,112 | 4,592
One iteration is 507 restarts in this case, but this has ran hundreds
of times and the results are always in line within margin of error.
This also holds true for metrics from live systems, same numbers.
Between 1.0s and 1.2s can be attributed by profiling to the time needed
for the service code itself to start up and sd_notify, the rest is spent
inside systemd's code.
This means there is currently a tradeoff for services - either use secure
images, or make restarting fast. Downtime of services is a very important
metric, as for many cases this directly translates to outages, total or
partial (blackouot or greyout).
In order to facilitate using secure images without downsides, skip the
slow dissect steps (probing, loop devices, etc) when the configured
image is a single filesystem dm-verity image with a policy that pins it
to a single filesystem, and an already existing and open dm-verity device
can be found and reused.
This allows orchestrators to pre-open images on download, before restarting
services, to minimize downtimes.
We should consider the whole init.scope trusted, and any
process trying to log on behalf of a unit there should be
attributed as so.
Follow-up for 4f25248b6e
Only with this commit is the change in effect.
Useful to extract a certificate from a hardware token to a file, for
example in mkosi to ship the certificate from a hardware token in
/usr/lib/verity.d in an image
Authenticated disk encryption is experimentally supported by cryptsetup
since v2.0.0 and allows for automatic dm-integrity setup for LUKS
devices. Add support for the mode to systemd-repart. The PR adds support
for `cryptsetup luksFormat --integrity` to systemd-repart and
"encryptedwithintegrity" dissection policy.
Limitations:
- No discard, online-only mode for repart.
Closes#39250
When a Yubikey or other fido2 device has FIPS mode enabled, UV will
always be required and cannot be disabled. Unhelpfully, when it is not
sent down, the hardware token (not the library) returns a generic
FIDO_ERR_MISSING_PARAMETER:
$ systemd-cryptenroll --fido2-device=auto --fido2-with-client-pin=no foo
<...>
libfido2: rx: payload_len=1
libfido2: fido_rx: buf=0x55c9ce170940, len=1
libfido2: 0000: 14
libfido2: cbor_parse_reply: blob[0]=0x14
libfido2: fido_dev_get_assert_rx: adjust_assert_count
Failed to ask token for assertion: FIDO_ERR_MISSING_PARAMETER
This can be set even when the token doesn't support UV (as in, fingerprint
reader), in which case using the PIN is required.
Check if 'alwaysUv' is set, and if not already configured, force
either UV (if available) or PIN when enrolling.
Now that we have Management Component Transport Protocol (MCTP) transports
available over USB, it would be helpful to apply udev's persistent
naming rules to MCTP interfaces, to follow the USB hub/port topology.
Enable persistent naming for ARPHRD_MCTP-type devices, using a "mc" name
prefix, and add appropriate definitions for the v260 naming sheme.
LUKS2 supports built-in integrity checking which may come very handy to
mitigate partial rollback attacks on the storage when only some specific
parts are restored to some old encrypted state. Specific use-cases like
Confidential VMs may want to mandate the usage of feature e.g. on the root
volume. Introduce "encryptedwithintegrity" image policy to support that.
Note, due to the current libcryptsetup limitations, checking whether the
feature is enabled or not for the 'file' case (e.g. DDI image as a raw file)
requires setting up a loop device. To avoid that and keep dissect fully
functional when working unpriviliged, implement a minimal custom LUKS header
parser.
Authenticated disk encryption is experimentally supported by cryptsetup since
v2.0.0 and allows for automatic dm-integrity setup for LUKS devices. Add
support for the mode to systemd-repart. Currently, the option can only be used
in 'online' mode as libcryptsetup does not support creating integrity data
without the use of in-kernel dm-integrity infrastructure.
Integrity=/IntegrityAlgorithm= are added in the anticipation of other integrity
protection options, e.g. enabling dm-integrity for a plain unencrypted
partition.
Before doing anything with the root directory file descriptor, let's
make sure we clone it first so that the caller can't mess with mount fd
attributes via mount_setattr() anymore.
We clone during parsing instead of in executor so that the caller can't
mess with the mount fd between invocations.
The kernel prevents you from open_tree()'ing an open_tree() fd unless it
was created from the caller's mount namespace. For various use cases, we
want to be able to open_tree() arbitrary mount file descriptors. Turns
out there's a way go get around it by mounting the mount file descriptor
in a throw-away mount namespace and then open_tree()'ing the mount file
descriptor. Let's implement this as a new helper mount_fd_clone() and
add a test for it.
Because move_mount()'ing the original fd makes it pretty useless as it
can't be move_mount()'ed again, we optionally make a second clone which
can replace the original fd so it can be cloned again later.
Currently, image_new() will calculate the image
path as the combination of dir_path and filename,
which is completely broken if filename is absolute
and dir_path is set.
Let's fix this by thoroughly cleaning up the
image_make() interface. Instead of having four
different arguments to pass in the image path,
let's reduce that to two, a file descriptor and a
path. If no file descriptor is provided, we create
own ourselves by opening the given path.
The callsites are updated to pass in an existing file
descriptor when available. Path calculation is moved
to callers instead of image_make().
Usually we gracefully ignore unknown configuration parameters, so that
service files can be written by upstreams and used across a variegated
range of distributions with various versions of systemd, to avoid
forcing users to the minimum common denominator and only adding settings
that are supported by the oldest distro supported.
Image policies do not behave like this, and any unknown partition or
policy designator causes the whole unit to fail to parse and a hard
error.
Change it so that parsing RootImagePolicy and friends via unit file or
D-Bus logs but otherwise ignores unknown specifiers, like other options
do.
This allows us to add new specifiers in the future, and users to adopt
them immediately.
Follow-up for d452335aa4
The path--as a whole--is no longer being opened with O_DIRECTORY, hence
the assertion is not valid.
Reproducer:
# SYSTEMD_RELAX_ESP_CHECKS=1 bootctl list --esp-path=`pwd`/README
Assertion 'S_ISDIR(sxa.stx_mode)' failed at src/shared/find-esp.c:295, function verify_fsroot_dir(). Aborting.
Follow-up-for: 63105f33ed
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2417917
Lennart Poettering
Daan De Meyer
Luca Boccassi
Luca Boccassi
Jeremy Kerr
Vitaly Kuznetsov
Yu Watanabe
David Tardon
Zbigniew Jędrzejewski-Szmek