shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-22 13:33:56 +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:
* systemd-measure is a new tool for precalculating and signing expected
TPM2 PCR values seen once a given unified kernel image (UKI) with
systemd-stub is booted. This is useful for implementing TPM2 policies
for LUKS encrypted volumes and encrypted system/service credentials,
that robustly bind to kernels carrying appropriate PCR signature
information. The signed expected PCR information, and the public key
used for the signature may be embedded inside UKIs for this purpose,
so that it is automatically available in userspace, once the UKI is
booted.
* systemd-measure is a new tool for calculating and signing expected
TPM2 PCR values for a given unified kernel image (UKI) booted via
sd-stub. The public key used for the signature and the signed
expected PCR information can be embedded inside the UKI. This
information can be extracted from the UKI by external tools and code
in the image itself and is made available to userspace in the booted
kernel.
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
kernel: when locking an encrypted volume/credential to the TPM
systemd-cryptenroll/systemd-creds will use the public key embedded in
the booted UKI to bind the volume/credential to the kernel (and
future versions thereof, as long as it carries PCR information signed
by the same key pair). When unlocking such an encrypted
volume/credential systemd-cryptsetup/systemd-creds will use the
signature embedded in the booted UKI to gain access.
systemd-cryptenroll/systemd-creds will use the public key to bind the
volume/credential to any kernel that carries PCR information signed
by the same key pair. When unlocking such volumes/credentials
systemd-cryptsetup/systemd-creds will use the signature embedded in
the booted UKI to gain access.
Binding TPM-based disk encryption to public keys/signatures of PCR
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
encryption now defaults to be locked to kernels which carry PCR
signatures from the same signature key pair. Example: if a
hypothetical distro FooOS prepares its UKIs like this, TPM-based disk
encryption is now – by default – bound to only FooOS kernels, and
encrypted volumes bound to the TPM cannot be unlocked on other
kernels from other sources. (But do note this behaviour requires
preparation/enabling in the UKI, and of course users can always
enroll non-TPM ways to unlock the volume.)
signatures from the same key pair. Example: if a hypothetical distro
FooOS prepares its UKIs like this, TPM-based disk encryption is now –
by default – bound to only FooOS kernels, and encrypted volumes bound
to the TPM cannot be unlocked on kernels from other sources. (But do
note this behaviour requires preparation/enabling in the UKI, and of
course users can always enroll non-TPM ways to unlock the volume.)
* systemd-pcrphase is a new tool that is invoked at 4 places during
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.
initrd start-up required @INITRD_USEC@ microseconds.
Initrd start-up required @INITRD_USEC@ microseconds.
Userspace start-up required @USERSPACE_USEC@ microseconds.

24
man/bootup.xml
View File

@ -202,22 +202,16 @@ emergency.service | | |
<refsect1>
<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
initrd follows the following structure.</para>
<para>Systemd can be used in the initrd as well. It detects the initrd environment by checking for the
<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
for the file <filename>/etc/initrd-release</filename>.
The default target in the initrd is
<filename>initrd.target</filename>. The bootup process begins
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.
Before any file systems are mounted, the manager will determine whether the system shall 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,
<filename>initrd-root-device.target</filename> is reached.