Pick up the two new sections in sd-stub and pass them as initrds into
the booted kernels, where they'll show up as
/.extra/tpm2-pcr-signature.json and /.extra/tpm2-pcr-public-key.pem in
the initrd file system.
The initrd is then supposed to pick these files up from there and save
them at a place that will survive into the host OS.
These aren't wired up yet to do anything useful. For now we just define
them.
This sections are supposed to carry a signature for expected
measurements on PCR 11 if this kernel is booted, in the JSON format
"systemd-measure sign" generates, and the public key used for the
signature.
The idea is to embedd the signature and the public key in unified
kernels and making them available to userspace, so that userspace can
easily access them and enroll (for which the public key is needed) or
unlock (for which the PCR signature is needed) LUKS2 volumes and
credentials that are bound to the currently used kernel version stream.
Why put these files in PE sections rather than just into simple files in
the initrd or into the host fs?
The signature cannot be in the initrd, since it is after all covering
the initrd, and thus the initrd as input for the calculation cannot
carry the result of the calculation. Putting the signature onto the root
fs sucks too, since we typically want to unlock the root fs with it,
hence it would be inaccessible for it's primary purpose then.
The public key could be in the initrd or in the root fs, there's no
technical restriction for that. However, I still think it's a good idea
to put it in a PE section as well, because this means the piece of code
that attaches the signature can also attach the public key easily in one
step, which is nice since it allows separating the roles of the
kernel/initrd/root fs builder, and the role of the signer, and the
former doesn't have to have knowledge about what the latter is going to
add to the image.
Note that the signature section is excluded from the TPM measurements
sd-stub does about its resource sections, since – as mentioned – it's
the expected output of the signing operation whose input are the
measurements, hence it cannot also be input to them. The public key
section is included in the measurements however.
Let's add simple helpers for passing data blobs from the stub into the
booted kernel as initrds that are generated on-the-fly.
(Note used yet, a later commit will make use of this)
* The new varlink interface exposes a method to subscribe to DNS
resolutions on the system. The socket permissions are open for owner and
group only.
* Notifications are sent to subscriber(s), if any, after successful
resolution of A and AAAA records.
This feature could be used by applications for auditing/logging services
downstream of the resolver. It could also be used to asynchronously
update the firewall. For example, a system that has a tightly configured
firewall could open up connections selectively to known good hosts based
on a known allow-list of hostnames. Of course, updating the firewall
asynchronously will require other design considerations (such as
queueing packets in the user space while a verdict is made).
See also:
https://lists.freedesktop.org/archives/systemd-devel/2022-August/048202.htmlhttps://lists.freedesktop.org/archives/systemd-devel/2022-February/047441.html
Previously, when an existing partition cannot grow, then entire process
fails. This makes such an existing partion handled as an foreign
partition, i.e. it is not managed by us.
The function context_allocate_partitions() may be called multiple times.
If this is called multiple times, then dropped partitions may still
assigned to free area.
The acquired size may be larger than the requested maximum. So, let's
cap the value.
Note, at the final phase, the acquired size should be larger than the
requested minimum. Hence, the assertion about that is added.
Previously, it did not return UINT64_MAX, but a huge value, as
`UINT64_MAX / grain_size * grain_size != UINT64_MAX`.
This also drops unnecessary conditions.
When LOOP_CONFIGURE fail, then it is not necessary to call it on any
later call of loop_configure(). Let's save the flag in a static variable
in the function.
In a couple of recent CI runs I noticed TEST-36 failing due to a missed
service exit notification and a subsequent fail of the `grep` command:
```
[ 257.112153] H systemd[1]: Started numa-test.service.
[ 257.114343] H systemd[899]: numa-test.service: Failed to set NUMA memory policy: Invalid argument
[ 257.118270] H systemd[899]: numa-test.service: Failed at step NUMA_POLICY spawning /bin/sleep: Invalid argument
[ 257.126170] H systemd[1]: Bus private-bus-connection: changing state RUNNING → CLOSING
[ 257.130290] H systemd[1]: numa-test.service: Failed to send unit change signal for numa-test.service: Connection reset by peer
[ 257.131567] H systemd[1]: Received SIGCHLD from PID 899 ((sleep)).
[ 257.132870] H systemd[1]: Got disconnect on private connection.
[ 257.134299] H systemd[1]: systemd-journald.service: Got notification message from PID 498 (FDSTORE=1)
[ 257.135611] H systemd[1]: systemd-journald.service: Added fd 38 (n/a) to fd store.
[ 257.136999] H systemd[1]: systemd-journald.service: Received EPOLLHUP on stored fd 38 (stored), closing.
[ 257.366996] H testsuite-36.sh[536]: + stopJournalctl
[ 257.366996] H testsuite-36.sh[536]: + local unit=init.scope
[ 257.366996] H testsuite-36.sh[536]: + echo 'Force journald to write all queued messages'
[ 257.366996] H testsuite-36.sh[536]: Force journald to write all queued messages
[ 257.366996] H testsuite-36.sh[536]: + journalctl --sync
[ 257.488642] H systemd-journald[498]: Received client request to rotate journal.
[ 257.520821] H testsuite-36.sh[536]: + journalctl -u init.scope --cursor-file=jounalCursorFile
[ 257.981399] H testsuite-36.sh[536]: + pid1StopUnit numa-test.service
[ 257.984533] H testsuite-36.sh[536]: + systemctl stop numa-test.service
[ 258.173656] H systemd[1]: Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
[ 258.180710] H systemd[1]: numa-test.service: Trying to enqueue job numa-test.service/stop/replace
[ 258.182424] H systemd[1]: Added job numa-test.service/stop to transaction.
[ 258.185234] H systemd[1]: numa-test.service: Installed new job numa-test.service/stop as 738
[ 258.187017] H systemd[1]: numa-test.service: Enqueued job numa-test.service/stop as 738
[ 258.239930] H testsuite-36.sh[536]: + grep 'numa-test.service: Main process exited, code=exited, status=242/NUMA' journal.log
```
Let's mitigate this by checking the test service exit status directly
instead of relying on the notification.
This splits out the JSON parser used by the systemd-cryptsetup code.
This is preparation for later work to reuse it in the tpm2 cryptsetup
token module, which currently uses a separate but very similar parser
for the same data.
No change in behaviour.
Traditionally, TPM2 PCR policies are bound against literal PCR values,
which makes them hard to work with when updating software that is
measured into PCRs: each update will change the PCR values, and thus
break TPM2 policies of existing objects.
Let's improve the situation: let's allow signed PCR policies. Secrets
and other TPM2 objects can be associated with a public key that signs a
PCR policy. Thus, if the signed policy and the public key is presented,
access to the TPM2 object can be granted. This allows a less brittle
handling of updates: for example, whenever a kernel image is updated a
new signed PCR policy can be shipped along with it, signed by a private
key owned by the kernel vendor (ideally: same private key that is used
to sign the kernel image itself). TPM2 objects can then be bound to the
associated public key, thus allowing objects that can only be unlocked
by kernels of the same vendor. This makes it very easy to update kernels
without affecting locked secrets.
This does not hook up any of the consuming code (just passes NULL/0
everywhere). This is for later commits.
Let's not output a title line given that we don't output multiple
different things here anyway, and the "bootctl list" command is about
listing boot entries anyway and it's documented that way.
Having titles for sections if we have mutliple sections of output
definitely makes sense, but if there's only one kind of information we
list it's redundant clutter.
