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
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
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.
Adds a new `SYSTEMD_NSS_RESOLVE_INTERFACE` environment variable to the nss-resolve module, whose value is subsequently passed down to the `ifindex` resolved lookup option.
This allows name lookups to be constrained to a just single interface for e.g. captive portal browsers.
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.
In aad0d11e7c we stopped supporting XBOOTLDR
with a different fs driver. This was the primary example that comes to mind
when we talk about loading filesystem drivers in the firmware. Since we don't
want people to do load such drivers, use a different example.
It is not entirely clear what happens when EnvironmentFile fails in the
prior wording. With the new wording it should now be clear that if it
fails to process the file the service will fail, and if it is prefixed
with "-" all errors are silently ignored.
Signed-off-by: Andrew Halaney <ahalaney@netflix.com>
Clarify in the docs that `if-safe` is the default by noting
that in the text for it, but also moving it to the first mentioned
option.
Make explicit in `man systemd-boot` that the `secure-boot-enroll`
option is specified in the `loader.conf`
Update an outdated comment in boot.c around the same.
Signed-off-by: Colin Walters <walters@verbum.org>
Make “effect” plural to indicate that BindsTo= also includes the other effects
of Requires= (like starting the listed units).
The documentation of Requires= already describes that the configuring unit is
stopped/restarted if any of the list units is explicitly stopped/restarted.
This made the previous wording “in addition to the effect of Requires, it
declares that if the unit bound to is stopped, this unit will be stopped too.”
ambiguous – this is no in addition, Requires= already does that, at least for
some (namely the explicit) cases.
Resolve this by making it clear what the actual difference to Requires= is and
further mention that this also includes failed units.
Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Add support for an empty Gateway= in [Network] to clear the existing
routes. This change will allow users to remove the default route from a
drop-in file.
Looking at the list, "test" or "testing" seems to be a fairly generic entry
that is missing from the list of suggestions. I went with "testing" because it
fits better with the other item, e.g. "staging".
In https://github.com/systemd/systemd/issues/38743 "laboratory" was also
suggested. I didn't include this because that is more about the location, not
deployment type. Any of the other deployments could be in a "laboratory".
Closes https://github.com/systemd/systemd/issues/38743.
`systemd.network(5)` recommends “that each filename is prefixed with a number
smaller than "70" (e.g. 10-eth0.network)”.
Reduce that used by the example accordingly, but stay above the number (`50`)
used in the earlier example for static configuration, so that would take
precedence over the dynamic one if both match for the same network.
The contents of file-hierarchy.7 have been copied over to the new page in
uapi-docs, and are already going stale here, since a bunch of additions and
improvements has been made there. OTOH, a commit was made here, but not there.
https://github.com/uapi-group/specifications/pull/172 updates the other doc.
OTOH, a reader should also read MOUNT_REQUIREMENTS if they care about what
systemd cares about. Thus, replace most of the text in our man page by a
reference to those two pages. In case we later want to list some disagreements
or differences wrt. LFSH, we can always add a paragraph or two here,
but having two documents with almost the same content is not going to work.
The output of `systemd-analyze exit-status` changed in commit
e04ed6db6b, so that the exit-status class
for EXIT_SUCCESS and EXIT_FAILURE is "libc" instead of "glibc".
This commit makes the example output in the man-page match the actual
output again.
Let's make sure that by default /dev/disk/by-label/ symlinks avoid
ambiguities, and the LUKS volume carries a different one than the file
system inside it.
Alternative-to: #39536
Let's synthesize DNS RRs for leases handed out by our DHCP server. This
way local VMs can have resolvable hostnames locally.
This does not implement reverse look ups for now. We can add this
later in similar fashion.
This introduces /run/systemd/resolve.hook/ as a new directory that local
(privileged) programs can bind a Varlink socket into. If they do they'll
get a method call for each attempted resolved lookup, which they can
then either process themselves (and generate new records for, or return
errors to block stuff) or let pass so that the regular resolution is
done.
Usecase for this is primarily two things:
1. in machined we can add local resolution of machine names to their IP
addresses, similar in fashion to nss-mymachines, but working also if
the non-NSS interfaces to name resolution are used, i.e. the local
DNS responder. In fact, I think we should eventually remove
nss-mymachines from our tree, as soon as this code in resolved is
setlled.
2. in networkd we can add local resolution of names specified in DHCP
leases we hand out.
But beyond that there should be many other uses, for example people
could write "dns firewalls" with this if they like where they
dynamically block certain names from resolution.
Fixes: #8518
Reverts systemd/systemd#38680
After taking a closer look I'm not convinced by the approach, see below.
First of all, all other SD_PATH_SEARCH_* are either somewhat generic,
i.e. encode the common prefix for configurations, binaries, etc., or are
subdirectories under systemd/ hence in our own "domain". The
tmpfiles/sysctl/binfmt we don't prefix with "systemd" precisely because
the concept is generic and there're actually other impls of them. A
specific SD_PATH_SEARCH_SYSCTL doesn't fit into our existing scheme.
Instead something along the lines of "SEARCH_SYSTEM_CONFIGURATION" shall
be introduced, and consumers will just suffix
sysctl.d/tmpfiles.d/binfmt.d for the final result.
And secondly, I don't grok why systemd-sysctl now unnecessarily calls
into sd-path to obtain the fixed search path. None of our other tools do
that.
-----------
An alternate approach, SD_PATH_SYSTEM_SEARCH_CONFIGURATION, which does
exactly above, will be introduced instead. It provides a universal
interface for querying any system config with our idiomatic
/etc/:/run/:/usr/local/lib/:/usr/lib/ hierarchy.
TPM2 support is not too useful if the firmware doesn't actually use it
for the boot chain, hence we require the full PC client profile support.
Let's make that clear in the docs.
Fixes: #38939
We do this in a separate service (rather than inside of
systemd-tpm2-setup), since we want failures of this measurement to
result in an instant reboot, like for most our measurements.
Failures to initialize nvpcrs, or allocate an SRK are somewhat OK (and
more likely), as long as this separator communicates clearly where they
have to have taken place, if they worked.
Sometimes it's hard to assign responsibility to a specific event source
for exiting when there's no more work to be done. So let's add exit-on-idle
support where we exit when there are no more event sources.
This enables running something like
"mkosi box -- run0 --empower --same-root-dir -E PATH" to get an
empowered session as the current user within the "mkosi box" environment.
Currently the only supported integrity algorithm using HMAC is
`hmac-sha256`. Add `hmac-sha512` to the list of supported algorithms as
well.
Also add the `PHMAC` integrity algorithm to the list of supported
algorithms. The `PHMAC` algorithm is like the regular HMAC algorithm,
but it takes a wrapped key as input. A key for the `PHMAC` algorithm is
an opaque key blob, who's physical size has nothing to do with the
cryptographic size. Such a wrapped key can for example be a HSM
protected key. Currently PHMAC is only available for the s390x
architecture (Linux on IBM Z).
Support for PHMAC has just been added to the cryptsetup project via MR
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/693 by commit
https://gitlab.com/cryptsetup/cryptsetup/-/commit/296eb39c60bd85228930caaea4bb1d2a766b7544
To allow automatic opening of integrity protected volumes that use PHMAC
via `/etc/integritytab`, this change in systemd's integritysetup tool is
needed as well.
This adds a new `Hostname=` option to the [DHCPServerStaticLease]
section in .network files, allowing an administrator to assign a
specific hostname to a client receiving a static lease.
We automatically select the correct DHCP option to use based on the
format of the provided string:
- Single DNS labels are sent as Option 12.
- Names with multiple DNS labels are sent as Option 81 in wire format.
Fixes: #39634
Add the PHMAC integrity algorithm to the list of supported algorithms.
The PHMAC algorithm is like the regular HMAC algorithm, but it takes a wrapped key
as input. A key for the PHMAC algorithm is an opaque key blob, who's physical size
has nothing to do with the cryptographic size. Currently PHMAC is only available
for the s390x architecture.