diff --git a/NEWS b/NEWS index f049e53b23..22893f51cd 100644 --- a/NEWS +++ b/NEWS @@ -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 diff --git a/catalog/systemd.catalog.in b/catalog/systemd.catalog.in index 977fe8285d..4c29128f71 100644 --- a/catalog/systemd.catalog.in +++ b/catalog/systemd.catalog.in @@ -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. diff --git a/man/bootup.xml b/man/bootup.xml index 4004e43d7f..31f7a31518 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -202,22 +202,16 @@ emergency.service | | | Bootup in the initrd - The initrd implementation can be set up using systemd as well. In this case, boot up inside the - initrd follows the following structure. + Systemd can be used in the initrd as well. It detects the initrd environment by checking for the + /etc/initrd-release file. The default target in the initrd is + initrd.target. The bootup process is identical to the system manager bootup until + the target basic.target. After that, systemd executes the special target + initrd.target. - systemd detects that it is run within an initrd by checking - for the file /etc/initrd-release. - The default target in the initrd is - initrd.target. The bootup process begins - identical to the system manager bootup (see above) until it - reaches basic.target. From there, systemd - approaches the special target initrd.target. - - 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 systemd-hibernate-resume@.service - which must be finished before local-fs-pre.target, - 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 + systemd-hibernate-resume@.service which must be finished before + local-fs-pre.target, so no filesystems can be mounted before the check is complete. When the root device becomes available, initrd-root-device.target is reached.