Add YAML frontmatter matching the style of other docs in the tree.
Bold grouped section topic names to make them visually distinct
from standalone items. Escape angle-bracket placeholders so GitHub
does not swallow them as HTML.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Rename TODO to TODO.md and convert to proper markdown format:
section headers become ## headings and bullet items use - instead
of *.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Items about the same topic were spread across the file as separate
bullet points instead of being collected under a single heading.
Consolidate them so each topic appears in one place. Compound
items that span multiple topics (e.g. cryptsetup/homed) are left
as standalone entries.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Normalize section header capitalization, add missing colons to
sub-topic headers, replace bullet character variants with dashes,
and fix sub-item indentation to use two spaces consistently.
Signed-off-by: Christian Brauner <brauner@kernel.org>
* 23ef56be00 Install new files for upstream build
* 98645a89ba Install new files for upstream build
* dc2dd78cc0 Install new files for upstream build
* aad316ec34 Drop wildcards, dh_exec does not suppor them for manpages
* 3bf8703dab Install new files for upstream build
* d1e92a6493 Update changelog for 260.1-1 release
* e7a80fe2b8 Install basic.conf in sd-standalone-sysusers package
* 48f796240e Add lpadmin group to basic.conf sysusers.d as requested by CUPS maintainer
* c15703b8aa Update changelog for 260-1 release
* f26cc52a43 Drop version from libselinux-dev dependency
* 7f3701ae2f Do not run "systemctl enable getty@.service" unconditionally
* ec59ddd832 Switch from libselinux1-dev to libselinux-dev
* 35258cd599 Update changelog for 260~rc4-1 release
* eb194c22ff Update changelog for 260~rc3-1 release
* a6878815d6 Really enable getty@ via packaging scriptlets
A malformed image can cause a division by zero, check that
the parameters are not zero.
Reported on yeswehackl.com as YWH-PGM9780-173
Follow-up for 0fa2cac4f0
Inspired by the discussion in #41161.
Also change the order of flags to be more logical. First the option
to specify at what fields we look, then the option to specify how we
return their name, the the value, and finally what to do if the value
is missing.
The fix in 8f1751a111 made me wonder if we could automatically detect
when pointers are accessed but when this might not be safe. Systemd
is already using a lot of `assert(dst)` and this change now forces
us to use them.
So this commit (ab)uses coccinelle to flag any pointer parameter
dereference not preceded by assert(param), ASSERT_PTR(param), or an
explicit NULL check. It adds integration into meson as a new "coccinelle"
test suite (just like clang-tidy) and is run in CI. The check is not
perfect but seems a reasonable heuristic.
For this RFC commit it is scoped to a subset, it excludes 25 dirs right
now and includes around 100. About 300 warnings left. Busywork that I am
happy to do if there is agreement that it is worth it.
With this in place we would have caught the bug from 8f1751a111 in CI:
```
FAIL: check-pointer-deref.cocci found issues in systemd/src/boot:
diff -u -p systemd/src/boot/measure.c /tmp/nothing/measure.c
--- systemd/src/boot/measure.c
+++ /tmp/nothing/measure.c
@@ -312,7 +312,6 @@ EFI_STATUS tpm_log_tagged_event(
if (err != EFI_SUCCESS)
return err;
- *ret_measured = true;
return EFI_SUCCESS;
}
```
This also adds a new POINTER_MAY_BE_NULL() for the cases when the
called function will do the NULL check (like `iovec_is_set()`).
Enabling locking by default would constitute a major footgun and
compatibility break on upgrades. This functionality is useful, but it
requires the rest of the system to be "ported" to use systemd-imds
first. The user or distro should opt in to "locked" mode only after
doing the integration work.
When doing large refactors or large changes the bot spams
labels left and right, making the PR unreadable. Use the
new option to limit the bot to a max of 5 file-based
labels. If more than 5 would be set, all file-based labels
are skipped.
In various scenarios it's useful to be able to run a software TPM as
fallback on a machine if it doesn't natively have a hardware for it, in
order to provide somewhat systematic interfacing for legacy machines.
This adds the infrastructure for it.
Relevant parts:
1. On EFI systems sd-stub will now generate a random secret on first
boot and store it in a persistent NV variable, which is marked
inaccessible to the OS. It then derives a per-OS secret from that which
is passed to the OS via the initrd logic. This is generally useful, but
in particular is intended to secure the software TPM at least a bit: it
provides better security than nothing (i.e. the only protection in place
is that the firmwrae protections work, but this is also what shim relies
on, hence maybe not too bad), and allows swtpm to encrypt its storage
with something.
2. systemd-tpm2-generator is extended to optionally start an swtpm if no
tpm hw is detected. Because this is of course a major downgrade in
security, this has to be requested explicitly at boot via a kernel
cmdline switch.
3. This optionally mounts the ESP from the initrd. This is general
infrastructure, and has been requested before, but is particularly
interesting in the context of software TPMs: the state needs to be
stored somewhere, and that before the rootfs can be unlocked.
4. This introduces a special new separator measurement for PCRs 0-7 that
isolates all measurements from pre-os/uefi world from those done by the
OS. I added this for three reasons:
- in the swtpm case we'll not have any pre-os/uefi measurements, and we
need to be able to determine cleanly that this is the case. this hence
is supposed to play a similar role as the usual firmware separator
measurement, that however cleanly fixates to the PCRs even the case
where the firmware measurements don't exist at all
- this is a very comprehensive fix for #40567
- not all firmwares generate the firmware separator at all, but it is
essential to seal off firmware variables from OS generated ones. This
can fill the void to some degree.
6. This introduces a new kernel cmdline switch
systemd.tpm2-measured-os=1, which allows force enabling all our
measurement logic, even if UKI TPM measurements are not done. This is
supposed to be used for the swtpm case so that one gets all the
measurements even without having the early boot verified boot chain in
place.
Benefits of all this: systems that care about TPMs have a (lower
security) compat glue in place that allows supporting legacy hw the same
way as modern hw in many ways, so that remote attestation and other uses
can reasonably work with the same codepaths.
Also see: https://github.com/lxc/incus-os/pull/667 regarding prior
similar work.
Fixes: #40567
This makes sure we don't use the "hardware" or "verity" nvpcrs before
the NV anchor measurement is done.
This is mostly to avoid confusing output, and to indirectly ensure the
nvpcr allocation in tpm2-setup is the load bearing one, but it should
not be load bearing for security afaics.
This has been requested previously for PCR 7 (#40567), but let's do that
for all firmware owned PCRs, since some firmwares forget to measure
their own separator. Let's hence measure our own guranteed one.
Fixes: #40567
The UKI public key PCR stuff only works if we get PCR measurements from
the pre-boot environment, hence automatically disable the logic by
default if we don't have that.
This is a potentially common case in VMs: firmwares might know the
concept of TPMs, but the hardware is not enabled in the specific VM.
Let's handle this case nicely.
So far we always conditioned our TPM magic on the UKI having detected
TPM support in the firmware. This is a bit limiting when we want to
support a software TPM that is not visible to the firmware. Hence let's
split this up, and add a separate control that can be set via the kernel
command line. However, as before, let's by default inherit the firmare
TPM discovery state into it, to retain the current behaviour unless
overriden.
With this in place, boot with "systemd.tpm2_measured_os=1
systemd.tpm2_software_fallback=1" on the kernel cmdline to get the swtpm
fallback and then a measured OS based on it.
In many cases it's essential to know if the firmware supports a TPM, but
in others we should accept it if the firmware doesn't have TPM support,
in particular if we want to run the OS with a software TPM.
Hence, add tpm2_is_mostly_supported() as function similar to
tpm2_is_fully_supported(), with the only difference that the former
doesn't insist on a firmware supported TPM. Then, change a number of
users over to this (but not all).
We want to start the software TPM fallback only if no real hw is
evailable and if the user opts-in to this behaviour. Add a generator
that drives all this, based on kernel command line configuration.
For TPM-less systems it's sometimes valuable to have a fill-in software
TPM running from early boot on, so that TPM-based functionality can
"just work" and rely on TPM semantics, even if it's at a substantially
weaker security level.
This adds a wrapper around swtpm. It's a binary that chainloads swtpm
but does a few preparatory steps and integrates into systemd's logic
otherwise.
All this is then exposed as systemd-tpm2-swtpm.service.
The service is not hooked into much yet, that is added in later commits.
When doing large refactors or large changes the bot spams
labels left and right, making the PR unreadable. Use the
new option to limit the bot to a max of 5 file-based
labels. If more than 5 would be set, all file-based labels
are skipped.
Before this commit, the > 0 state of arg_newline tristate is
simply ignored.
Yes, this is a minor compat break, but I'd argue the previous
behavior was not useful as "yes" is treated the same as "auto".
An issue also reported that it was quite surprising.
Fixes#41348
The comment about `SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)` is
incorrect. To quote @YHNdnzj:
```
nah, the capability-based permission model is a legacy from kdbus. We cannot do it race-freely without it. Please simply drop the comment.
```
Thanks to @YHNdnzj for suggesting this.
The manager_do_set_objective() was doing a bunch of work to
check the `root` path that can already be done via
`json_dispatch_path` so instead of duplicating use the helper.
Thanks to @YHNdnzj for suggesting this.
Drop the _manager suffix for vl_method_{poweroff,{soft,}reboot,
halt,kexec}_manager.
They're unambiguous enough and the power mgmt operations are
not manager-wide but system-wide.
Thanks to @YHNdnzj for suggesting this.
We need to store state persistently for the software TPM (i.e. the root
key). But given that TPMs are generally used to unlock the rootfs, this
storage cannot be on the rootfs. Hence let's use the ESP instead, as the
next best thing, that is guaranteed to exist during early boot, given we
just were booted from it.
This defines automatic logic for this, but does not cause the ESP mount
job to be enqueued (since typically we don't actually want that
mounted), this is left for the actual services that needs to be done.
Note that the mount here is set up quite differently from the one from
the host: since initrds are short-lived anyway, it seemed pointless to
use autofs. Moreover this uses a fixed place to mount the ESP, inspired
by the /sysroot/ + /sysusr/ mount naming. All that to simplify things a
bit for the consumers (which is mostly swtpm)
This change aligns the behaviour of UKI generation with the behaviour
of BLS. The latter filters out lines starting with a #, allowing users
to add comments and/or temporarily remove some flags from the kernel
command line.
The kernel-install test have been adjusted to use a multiline cmdline
with a comment in it. Without this patch, the test fails.
This adds a new cloud IMDS client, that can cover AWS, Azure, GCP,
Hetzner imds to varying degrees. Each cloud has this and it's very basic
functionality, hence I think it makes sense to add this to systemd.
Since the clouds are all different this tries hard to do the abstract
common logic in code, but encode the endpoint details, and well-known
keys in hwdb, attached to the DMI id device.
Why all this?
* Efficiency: we can schedule this in the initrd, at the earliest points
possible, without unnecessary delays
* Robustness: imds is typically slow and/or heavily rate-limited:
systemd-imdsd as single entrypoint can deal with that, and provide a
reliable, cached interface
* Security: the idea is that systemd-imdsd is the only service behing
able to access the IMDS HTTP, and the host carries a blackhole route for
it otherwise. That way sensitive info can be kept away from clients, and
requires polkit auth for access
* Simplicity: extraction of systemd's system credentials from IMDS
userdata happens with systemd's own infra, and for many usecases that
should already be enough.
* Measurements: before accepting the IDMS userdata, it can be measured
into a PCR, as any other configuration input for the system
Fixes: #40763
Pass side, start_line, and start_side through to createReviewComment()
when present, enabling multi-line review comments. Update the prompt to
document all positioning fields using JSON Schema and make line required.
A malformed bmp with 8bits depth but smaller color
map would cause out of bounds reads. This is not a real
problem as the image is signed, but better to be safe.
Reported on yeswehack.com as:
YWH-PGM9780-135
Follow-up for 0fa2cac4f0
Christian Brauner
Mike Yuan
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Michael Vogt
Lennart Poettering
Cynthia
Daan De Meyer