shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-01-12 13:18:14 +03:00
Code

Merge pull request #24986 from keszybz/news-systemd-measure

Browse Source 
NEWS: rework the description of systemd-measure a bit again
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2022-10-17 13:24:07 +02:00 committed by GitHub
commit 70427ec553
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 29 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
NEWS
View File

@ -39,25 +39,22 @@ CHANGES WITH 252 in spe:
New Features: New Features:
* systemd-measure is a new tool for precalculating and signing expected * systemd-measure is a new tool for calculating and signing expected
TPM2 PCR values seen once a given unified kernel image (UKI) with TPM2 PCR values for a given unified kernel image (UKI) booted via
systemd-stub is booted. This is useful for implementing TPM2 policies sd-stub. The public key used for the signature and the signed
for LUKS encrypted volumes and encrypted system/service credentials, expected PCR information can be embedded inside the UKI. This
that robustly bind to kernels carrying appropriate PCR signature information can be extracted from the UKI by external tools and code
information. The signed expected PCR information, and the public key in the image itself and is made available to userspace in the booted
used for the signature may be embedded inside UKIs for this purpose, kernel.
so that it is automatically available in userspace, once the UKI is
booted.
systemd-cryptsetup, systemd-cryptenroll and systemd-creds have been systemd-cryptsetup, systemd-cryptenroll, and systemd-creds have been
updated to make use of this information if available in the booted updated to make use of this information if available in the booted
kernel: when locking an encrypted volume/credential to the TPM kernel: when locking an encrypted volume/credential to the TPM
systemd-cryptenroll/systemd-creds will use the public key embedded in systemd-cryptenroll/systemd-creds will use the public key to bind the
the booted UKI to bind the volume/credential to the kernel (and volume/credential to any kernel that carries PCR information signed
future versions thereof, as long as it carries PCR information signed by the same key pair. When unlocking such volumes/credentials
by the same key pair). When unlocking such an encrypted systemd-cryptsetup/systemd-creds will use the signature embedded in
volume/credential systemd-cryptsetup/systemd-creds will use the the booted UKI to gain access.
signature embedded in the booted UKI to gain access.
Binding TPM-based disk encryption to public keys/signatures of PCR Binding TPM-based disk encryption to public keys/signatures of PCR
values — instead of literal PCR values — addresses the inherent values — instead of literal PCR values — addresses the inherent
@ -68,13 +65,12 @@ CHANGES WITH 252 in spe:
Net effect: if you boot a properly prepared kernel, TPM-bound disk Net effect: if you boot a properly prepared kernel, TPM-bound disk
encryption now defaults to be locked to kernels which carry PCR encryption now defaults to be locked to kernels which carry PCR
signatures from the same signature key pair. Example: if a signatures from the same key pair. Example: if a hypothetical distro
hypothetical distro FooOS prepares its UKIs like this, TPM-based disk FooOS prepares its UKIs like this, TPM-based disk encryption is now –
encryption is now – by default – bound to only FooOS kernels, and by default – bound to only FooOS kernels, and encrypted volumes bound
encrypted volumes bound to the TPM cannot be unlocked on other to the TPM cannot be unlocked on kernels from other sources. (But do
kernels from other sources. (But do note this behaviour requires note this behaviour requires preparation/enabling in the UKI, and of
preparation/enabling in the UKI, and of course users can always course users can always enroll non-TPM ways to unlock the volume.)
enroll non-TPM ways to unlock the volume.)
* systemd-pcrphase is a new tool that is invoked at 4 places during * systemd-pcrphase is a new tool that is invoked at 4 places during
system runtime, and measures additional words into TPM2 PCR 11, to system runtime, and measures additional words into TPM2 PCR 11, to

2
catalog/systemd.catalog.in
View File

@ -144,7 +144,7 @@ might still be busy with completing start-up.
Kernel start-up required @KERNEL_USEC@ microseconds. Kernel start-up required @KERNEL_USEC@ microseconds.
initrd start-up required @INITRD_USEC@ microseconds. Initrd start-up required @INITRD_USEC@ microseconds.
Userspace start-up required @USERSPACE_USEC@ microseconds. Userspace start-up required @USERSPACE_USEC@ microseconds.

24
man/bootup.xml
View File

@ -202,22 +202,16 @@ emergency.service | | |
<refsect1> <refsect1>
<title>Bootup in the initrd</title> <title>Bootup in the initrd</title>
<para>The initrd implementation can be set up using systemd as well. In this case, boot up inside the <para>Systemd can be used in the initrd as well. It detects the initrd environment by checking for the
initrd follows the following structure.</para> <filename>/etc/initrd-release</filename> file. The default target in the initrd is
<filename>initrd.target</filename>. The bootup process is identical to the system manager bootup until
the target <filename>basic.target</filename>. After that, systemd executes the special target
<filename>initrd.target</filename>.
<para>systemd detects that it is run within an initrd by checking Before any file systems are mounted, the manager will determine whether the system shall resume from
for the file <filename>/etc/initrd-release</filename>. hibernation or proceed with normal boot. This is accomplished by
The default target in the initrd is <filename>systemd-hibernate-resume@.service</filename> which must be finished before
<filename>initrd.target</filename>. The bootup process begins <filename>local-fs-pre.target</filename>, so no filesystems can be mounted before the check is complete.
identical to the system manager bootup (see above) until it
reaches <filename>basic.target</filename>. From there, systemd
approaches the special target <filename>initrd.target</filename>.
Before any file systems are mounted, it must be determined whether
the system will resume from hibernation or proceed with normal boot.
This is accomplished by <filename>systemd-hibernate-resume@.service</filename>
which must be finished before <filename>local-fs-pre.target</filename>,
so no filesystems can be mounted before the check is complete.
When the root device becomes available, When the root device becomes available,
<filename>initrd-root-device.target</filename> is reached. <filename>initrd-root-device.target</filename> is reached.