dasharo/systemd
0
0
Fork 0
mirror of https://github.com/Dasharo/systemd.git synced 2026-03-06 15:02:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #26023 from keszybz/man-page-updates

Browse Source 
Man page updates
This commit is contained in:
Luca Boccassi
2023-01-11 23:05:27 +00:00
committed by GitHub
parent 41fca8686f 86a066157e
commit c24b0bd1df
32 changed files with 175 additions and 160 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
catalog/systemd.catalog.in
View File

@@ -533,9 +533,10 @@ Subject: TPM PCR Extended
Defined-By: systemd
Support: %SUPPORT_URL%
The string '@MEASURING@' has been extended into Trusted Platform Module's (TPM)
Platform Configuration Register (PCR) @PCR@, on banks @BANKS@.
The Trusted Platform Module's (TPM) Platform Configuration Register (PCR)
@PCR@, on banks @BANKS@, has been extended with the string '@MEASURING@'.
Whenever the system transitions to a new runtime phase, a different string is
extended into the specified PCR, to ensure that security policies for TPM-bound
secrets and other resources are limited to specific phases of the runtime.
Whenever the system transitions to a new runtime phase, the specified PCR is
extended with a different string, to ensure that security policies for
TPM-bound secrets and other resources are limited to specific phases of the
runtime.

2
man/bootctl.xml
View File

@@ -429,7 +429,7 @@
<programlisting>$ <command>bootctl status</command>
System:
Firmware: UEFI 2.40 (<replaceable>firmware-version</replaceable>) ← firmware vendor and version
Secure Boot: disabled (setup) ← secure boot status
Secure Boot: disabled (setup) ← Secure Boot status
TPM2 Support: yes
Boot into FW: supported ← does the firmware support booting into itself

5
man/journalctl.xml
View File

@@ -18,7 +18,7 @@
<refnamediv>
<refname>journalctl</refname>
<refpurpose>Print log entries from the the systemd journal</refpurpose>
<refpurpose>Print log entries from the systemd journal</refpurpose>
</refnamediv>
<refsynopsisdiv>
@@ -664,7 +664,8 @@
<refsect1>
<title>Forward Secure Sealing (FSS) Options</title>
<para>The following options make be used together with the <option>--setup-keys</option> command, see below.</para>
<para>The following options may be used together with the <option>--setup-keys</option> command described
below:</para>
<variablelist>
<varlistentry>

4
man/kernel-install.xml
View File

@@ -198,8 +198,8 @@
<para><varname>$KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired machine-id to
use. It's always a 128-bit ID. Normally it's read from <filename>/etc/machine-id</filename>, but it can
also be overridden via <varname>$MACHINE_ID</varname> (see below). If not specified via these methods a
fallback value will generated by <command>kernel-install</command>, and used only for a single
also be overridden via <varname>$MACHINE_ID</varname> (see below). If not specified via these methods,
a fallback value will generated by <command>kernel-install</command> and used only for a single
invocation.</para>
<para><varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> is set for the plugins to the desired entry

31
man/loader.conf.xml
View File

@@ -228,19 +228,22 @@
<listitem><para>Danger: this feature might soft-brick your device if used improperly.</para>
<para>Takes one of <literal>off</literal>, <literal>manual</literal> or <literal>force</literal>.
Controls the enrollment of secure boot keys. If set to <literal>off</literal>, no action whatsoever
Controls the enrollment of Secure Boot keys. If set to <literal>off</literal>, no action whatsoever
is taken. If set to <literal>manual</literal> (the default) and the UEFI firmware is in setup-mode
then entries to manually enroll Secure Boot variables are created in the boot menu. If set to
<literal>force</literal>, in addition, if a directory named <filename>/loader/keys/auto/</filename>
exists on the ESP then the keys in that directory are enrolled automatically.</para>
<para>The different sets of variables can be set up under <filename>/loader/keys/<replaceable>NAME</replaceable></filename>
where <replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry.
This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.</para>
<para>The different sets of variables can be set up under
<filename>/loader/keys/<replaceable>NAME</replaceable></filename> where
<replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry. This
allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.
</para>
<para>Supported secure boot variables are one database for authorized images, one key exchange key (KEK)
and one platform key (PK). For more information, refer to the <ulink url="https://uefi.org/specifications">UEFI specification</ulink>,
under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the
<para>Supported Secure Boot variables are one database for authorized images, one key exchange key
(KEK) and one platform key (PK). For more information, refer to the <ulink
url="https://uefi.org/specifications">UEFI specification</ulink>, under Secure Boot and Driver
Signing. Another resource that describe the interplay of the different variables is the
<ulink url="https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot">
EDK2 documentation</ulink>.</para>
@@ -294,17 +297,17 @@ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
<para>Work around BitLocker requiring a recovery key when the boot loader was
updated (disabled by default).</para>
<para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found
and Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal>
EFI variable and restart the system. The firmware will then start Windows Boot Manager
directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption
key. This allows systemd-boot to be updated without having to provide the recovery key for
BitLocker drive unlocking.</para>
<para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found and
Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal> EFI variable
and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM
PCRs in expected states so that Windows can unseal the encryption key. This allows
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> to
be updated without having to provide the recovery key for BitLocker drive unlocking.</para>
<para>Note that the PCRs that Windows uses can be configured with the
<literal>Configure TPM platform validation profile for native UEFI firmware configurations</literal>
group policy under <literal>Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption</literal>.
When secure boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
When Secure Boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
The TPM key protector needs to be removed and then added back for the PCRs on an already
encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed
up booting into Windows.</para></listitem>

4
man/nss-myhostname.xml
View File

@@ -109,7 +109,9 @@ rpc: db files
netgroup: nis</programlisting>
<para>To test, use <command>glibc</command>'s <command>getent</command> tool:</para>
<para>To test, use <command>glibc</command>'s
<citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool:</para>
<programlisting>$ getent ahosts `hostname`
::1 STREAM omega

12
man/os-release.xml
View File

@@ -451,12 +451,12 @@
<varlistentry>
<term><varname>PORTABLE_PREFIXES=</varname></term>
<listitem><para>Takes a space-separated list of one or more valid prefix match strings for the
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> logic. This field
serves two purposes: it is informational, identifying portable service images as such (and thus
allowing them to be distinguished from other OS images, such as bootable system images). It is also
used when a portable service image is attached: the specified or implied portable service prefix is
checked against the list specified here, to enforce restrictions how images may be attached to a
system.</para></listitem>
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink> logic.
This field serves two purposes: it is informational, identifying portable service images as such
(and thus allowing them to be distinguished from other OS images, such as bootable system images).
It is also used when a portable service image is attached: the specified or implied portable
service prefix is checked against the list specified here, to enforce restrictions how images may
be attached to a system.</para></listitem>
</varlistentry>
</variablelist>
</refsect2>

11
man/pam_systemd_home.xml
View File

@@ -97,13 +97,14 @@
<refsect1>
<title>Module Types Provided</title>
<para>The module implements all four PAM operations: <option>auth</option> (reason: to allow
authentication using the encrypted data), <option>account</option> (reason: users with
<para>The module implements all four PAM operations: <option>auth</option> (to allow authentication using
the encrypted data), <option>account</option> (because users with
<filename>systemd-homed.service</filename> user accounts are described in a <ulink
url="https://systemd.io/USER_RECORD/">JSON user record</ulink> and may be configured in more detail than
in the traditional Linux user database), <option>session</option> (user sessions must be tracked in order
to implement automatic release when the last session of the user is gone), <option>password</option> (to
change the encryption password — also used for user authentication — through PAM).</para>
in the traditional Linux user database), <option>session</option> (because user sessions must be tracked
in order to implement automatic release when the last session of the user is gone),
<option>password</option> (to change the encryption password — also used for user authentication —
through PAM).</para>
</refsect1>
<refsect1>

4
man/portablectl.xml
View File

@@ -48,7 +48,7 @@
and transfer them as a whole between systems. When these images are attached the local system the contained units
may run in most ways like regular system-provided units, either with full privileges or inside strict sandboxing,
depending on the selected configuration. For more details, see
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>.</para>
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.</para>
<para>Specifically portable service images may be of the following kind:</para>
@@ -367,7 +367,7 @@
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
Images can be block images, btrfs subvolumes or directories. For more information on portable
services with extensions, see the <literal>Extension Images</literal> paragraph on
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>.
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.
</para>
<para>Note that the same extensions have to be specified, in the same order, when attaching

10
man/repart.d.xml
View File

@@ -427,9 +427,11 @@
<para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para>
<para>When <command>systemd-repart</command> is invoked with the <option>--image=</option> or
<option>--root=</option> command line switches the source paths specified are taken relative to the
specified root directory or disk image root.</para></listitem>
<para>When
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
is invoked with the <option>--image=</option> or <option>--root=</option> command line switches the
source paths specified are taken relative to the specified root directory or disk image root.
</para></listitem>
</varlistentry>
<varlistentry>
@@ -492,7 +494,7 @@
to <literal>off</literal> or <literal>data</literal>, the partition is populated with content as
specified by <varname>CopyBlocks=</varname> or <varname>CopyFiles=</varname>. If set to
<literal>hash</literal>, the partition will be populated with verity hashes from the matching verity
data partition. If set to <literal>signature</literal>, The partition will be populated with a JSON
data partition. If set to <literal>signature</literal>, the partition will be populated with a JSON
object containing a signature of the verity root hash of the matching verity hash partition.</para>
<para>A matching verity partition is a partition with the same verity match key (as configured with

4
man/systemd-boot.xml
View File

@@ -56,7 +56,7 @@
<listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware.</para></listitem>
<listitem><para>Secure boot variables enrollement if the UEFI firmware is in setup-mode and files are provided
<listitem><para>Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided
on the ESP.</para></listitem>
</itemizedlist>
@@ -95,7 +95,7 @@
with a 'system token' stored in a persistent EFI variable and derives a random seed to use by the OS as
entropy pool initialization, providing a full entropy pool during early boot.</para></listitem>
<listitem><para>The boot manager allows for secure boot variables to be enrolled if the UEFI firmware is
<listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is
in setup-mode. Additionally, variables can be automatically enrolled if configured.</para></listitem>
</itemizedlist>

2
man/systemd-creds.xml
View File

@@ -359,7 +359,7 @@
<listitem><para>Takes a path to a TPM2 PCR signature file as generated by the
<citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool and that may be used to allow the <command>decrypt</command> command to decrypt credentials that
are bound to specific signed PCR values. If this this is not specified explicitly, and a credential
are bound to specific signed PCR values. If this is not specified explicitly, and a credential
with a signed PCR policy is attempted to be decrypted, a suitable signature file
<filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
<filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and

6
man/systemd-cryptenroll.xml
View File

@@ -288,7 +288,7 @@
<row>
<entry>7</entry>
<entry>Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR.</entry>
<entry>Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR.</entry>
</row>
<!-- Grub measures all its commands and the kernel command line into PCR 8… -->
@@ -312,7 +312,7 @@
<row>
<entry>12</entry>
<entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any specified kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. (Note that if <command>systemd-boot</command> and <command>systemd-stub</command> are used in combination the command line might be measured twice!)</entry>
<entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. (Note that if <command>systemd-boot</command> and <command>systemd-stub</command> are used in combination the command line might be measured twice!)</entry>
</row>
<row>
@@ -382,7 +382,7 @@
<para>The <option>--tpm2-signature=</option> option takes a path to a TPM2 PCR signature file
as generated by the
<citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool. If this this is not specified explicitly a suitable signature file
tool. If this is not specified explicitly a suitable signature file
<filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
<filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and
used. If a signature file is specified or found it is used to verify if the volume can be unlocked

8
man/systemd-cryptsetup-generator.xml
View File

@@ -63,7 +63,7 @@
<literal>no</literal>, causes the generator to ignore any devices configured in
<filename>/etc/crypttab</filename> (<varname>luks.uuid=</varname> will still work however).
<varname>rd.luks.crypttab=</varname> is honored only in initrd while
<varname>luks.crypttab=</varname> is honored by both the main system and the initrd.
<varname>luks.crypttab=</varname> is honored by both the main system and in the initrd.
</para></listitem>
</varlistentry>
@@ -75,7 +75,7 @@
part of the boot process as if it was listed in <filename>/etc/crypttab</filename>. This option may
be specified more than once in order to set up multiple devices. <varname>rd.luks.uuid=</varname> is
honored only in the initrd, while <varname>luks.uuid=</varname> is honored by both the main system
and the initrd.</para>
and in the initrd.</para>
<para>If <filename>/etc/crypttab</filename> contains entries with the same UUID, then the name,
keyfile and options specified there will be used. Otherwise, the device will have the name
@@ -101,7 +101,7 @@
<manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
<para><varname>rd.luks.name=</varname> is honored only in the initrd, while
<varname>luks.name=</varname> is honored by both the main system and the initrd.</para>
<varname>luks.name=</varname> is honored by both the main system and in the initrd.</para>
</listitem>
</varlistentry>
@@ -203,7 +203,7 @@
<para><varname>rd.luks.options=</varname> is honored only by initial
RAM disk (initrd) while <varname>luks.options=</varname> is
honored by both the main system and the initrd.</para>
honored by both the main system and in the initrd.</para>
</listitem>
</varlistentry>
</variablelist>

4
man/systemd-integritysetup-generator.xml
View File

@@ -27,8 +27,8 @@
<refsect1>
<title>Description</title>
<para><filename>systemd-integritysetup-generator</filename> is a generator that translates <filename>/etc/integritytab</filename> entries into
native systemd units early at boot. This will create
<para><command>systemd-integritysetup-generator</command> is a generator that translates
<filename>/etc/integritytab</filename> entries into native systemd units early at boot. This will create
<citerefentry><refentrytitle>systemd-integritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
units as necessary.</para>

29
man/systemd-measure.xml
View File

@@ -78,12 +78,13 @@
seen in TPM2 PCR register 11 after boot-up of a unified kernel image. Then, cryptographically sign
the resulting values with the private/public key pair (RSA) configured via
<option>--private-key=</option> and <option>--public-key=</option>. This will write a JSON object to
standard output that contains signatures for all specified PCR banks (see
<option>--pcr-bank=</option>) below, which may be used to unlock encrypted credentials (see
standard output that contains signatures for all specified PCR banks (see the
<option>--pcr-bank=</option> option below), which may be used to unlock encrypted credentials (see
<citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>) or
LUKS volumes (see
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This
allows binding secrets to a set of kernels for which such PCR 11 signatures can be provided.</para>
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
This allows binding secrets to a set of kernels for which such PCR 11 signatures can be
provided.</para>
<para>Note that a TPM2 device must be available for this signing to take place, even though the
result is not tied to any TPM2 device or its state.</para></listitem>
@@ -98,13 +99,13 @@
<variablelist>
<varlistentry>
<term><option>--linux=PATH</option></term>
<term><option>--osrel=PATH</option></term>
<term><option>--cmdline=PATH</option></term>
<term><option>--initrd=PATH</option></term>
<term><option>--splash=PATH</option></term>
<term><option>--dtb=PATH</option></term>
<term><option>--pcrpkey=PATH</option></term>
<term><option>--linux=<replaceable>PATH</replaceable></option></term>
<term><option>--osrel=<replaceable>PATH</replaceable></option></term>
<term><option>--cmdline=<replaceable>PATH</replaceable></option></term>
<term><option>--initrd=<replaceable>PATH</replaceable></option></term>
<term><option>--splash=<replaceable>PATH</replaceable></option></term>
<term><option>--dtb=<replaceable>PATH</replaceable></option></term>
<term><option>--pcrpkey=<replaceable>PATH</replaceable></option></term>
<listitem><para>When used with the <command>calculate</command> or <command>sign</command> verb,
configures the files to read the unified kernel image components from. Each option corresponds with
@@ -122,7 +123,7 @@
</varlistentry>
<varlistentry>
<term><option>--bank=DIGEST</option></term>
<term><option>--bank=<replaceable>DIGEST</replaceable></option></term>
<listitem><para>Controls the PCR banks to pre-calculate the PCR values for – in case
<command>calculate</command> or <command>sign</command> is invoked –, or the banks to show in the
@@ -132,8 +133,8 @@
</varlistentry>
<varlistentry>
<term><option>--private-key=PATH</option></term>
<term><option>--public-key=PATH</option></term>
<term><option>--private-key=<replaceable>PATH</replaceable></option></term>
<term><option>--public-key=<replaceable>PATH</replaceable></option></term>
<listitem><para>These switches take paths to a pair of PEM encoded RSA key files, for use with
the <command>sign</command> command.</para>

2
man/systemd-nspawn.xml
View File

@@ -1374,7 +1374,7 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
<itemizedlist>
<listitem><para>If <option>noidmap</option> is used, any user <option>z</option> in the range
<option>0 … y</option> seen from inside of the container is mapped to <option>x + z</option> in the
<option>x … x + y</option> range on the host. All host users outside of that range are mapped to
<option>x … x + y</option> range on the host. Other host users are mapped to
<option>nobody</option> inside the container.</para></listitem>
<listitem><para>If <option>idmap</option> is used, any user <option>z</option> in the UID range
<option>0 … y</option> as seen from inside the container is mapped to the same <option>z</option>

3
man/systemd-oomd.service.xml
View File

@@ -36,7 +36,8 @@
<para>You can enable monitoring and actions on units by setting <varname>ManagedOOMSwap=</varname> and
<varname>ManagedOOMMemoryPressure=</varname> in the unit configuration, see
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
<command>systemd-oomd</command> retrieves information about such units from <command>systemd</command>
<command>systemd-oomd</command> retrieves information about such units from
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
when it starts and watches for subsequent changes.</para>
<para>Cgroups of units with <varname>ManagedOOMSwap=</varname> or

94
man/systemd-pcrphase.service.xml
View File

@@ -35,75 +35,73 @@
<title>Description</title>
<para><filename>systemd-pcrphase.service</filename>,
<filename>systemd-pcrphase-sysinit.service</filename> and
<filename>systemd-pcrphase-sysinit.service</filename>, and
<filename>systemd-pcrphase-initrd.service</filename> are system services that measure specific strings
into TPM2 PCR 11 during boot at various milestones of the boot process.</para>
<para>These services require
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> to be
used in a unified kernel image (UKI) setup. They execute no operation when invoked when the stub has not
been used to invoke the kernel. The stub will measure the invoked kernel and associated vendor resources
into PCR 11 before handing control to it; once userspace is invoked these services then will extend
certain literal strings indicating various phases of the boot process into TPM2 PCR 11. During a regular
boot process the following strings are extended into PCR 11.</para>
used in a unified kernel image (UKI). They execute no operation when the stub has not been used to invoke
the kernel. The stub will measure the invoked kernel and associated vendor resources into PCR 11 before
handing control to it; once userspace is invoked these services then will extend TPM2 PCR 11 with certain
literal strings indicating phases of the boot process. During a regular boot process the following
strings are used:</para>
<orderedlist>
<listitem><para><literal>enter-initrd</literal> is extended into PCR 11 early when the initrd
initializes, before activating system extension images for the initrd. It is supposed to act as barrier
between the time where the kernel initializes, and where the initrd starts operating and enables
system extension images, i.e. code shipped outside of the UKI. (This string is extended at start of
<filename>systemd-pcrphase-initrd.service</filename>.)</para></listitem>
<listitem><para><literal>enter-initrd</literal> — early when the initrd initializes, before activating
system extension images for the initrd. It acts as a barrier between the time where the kernel
initializes and where the initrd starts operating and enables system extension images, i.e. code
shipped outside of the UKI. (This extension happens when
<filename>systemd-pcrphase-initrd.service</filename> is started.)</para></listitem>
<listitem><para><literal>leave-initrd</literal> is extended into PCR 11 when the initrd is about to
transition into the host file system, i.e. when it achieved its purpose. It is supposed to act as
barrier between kernel/initrd code and host OS code. (This string is extended at stop of
<filename>systemd-pcrphase-initrd.service</filename>.)</para></listitem>
<listitem><para><literal>leave-initrd</literal> — when the initrd is about to transition into the host
file system. It acts as barrier between initrd code and host OS code. (This extension happens when
<filename>systemd-pcrphase-initrd.service</filename> is stopped.)</para></listitem>
<listitem><para><literal>sysinit</literal> is extended into PCR 11 when basic system initialization is
complete (which includes local file systems have been mounted), and the system begins starting regular
system services. (This string is extended at start of
<filename>systemd-pcrphase-sysinit.service</filename>.)</para></listitem>
<listitem><para><literal>sysinit</literal> — when basic system initialization is complete (which
includes local file systems having been mounted), and the system begins starting regular system
services. (This extension happens when <filename>systemd-pcrphase-sysinit.service</filename> is
started.)</para></listitem>
<listitem><para><literal>ready</literal> is extended into PCR 11 during later boot-up, after remote
file systems have been activated (i.e. after <filename>remote-fs.target</filename>), but before users
are permitted to log in (i.e. before <filename>systemd-user-sessions.service</filename>). It is
supposed to act as barrier between the time where unprivileged regular users are still prohibited to
log in and where they are allowed to log in. (This string is extended at start of
<filename>systemd-pcrphase.service</filename>.)</para></listitem>
<listitem><para><literal>ready</literal> — during later boot-up, after remote file systems have been
activated (i.e. after <filename>remote-fs.target</filename>), but before users are permitted to log in
(i.e. before <filename>systemd-user-sessions.service</filename>). It acts as barrier between the time
where unprivileged regular users are still prohibited to log in and where they are allowed to log in.
(This extension happens when <filename>systemd-pcrphase.service</filename> is started.)
</para></listitem>
<listitem><para><literal>shutdown</literal> is extended into PCR 11 when system shutdown begins. It is
supposed to act as barrier between the time the system is fully up and running and where it is about to
shut down. (This string is extended at stop of
<filename>systemd-pcrphase.service</filename>.)</para></listitem>
<listitem><para><literal>final</literal> is extended into PCR 11 at the end of system shutdown. It is
supposed to act as barrier between the time the service manager still runs and when it transitions into
the final boot phase where service management is not available anymore. (This string is extended at
stop of <filename>systemd-pcrphase-sysinit.service</filename>.)</para></listitem>
<listitem><para><literal>shutdown</literal> — when the system shutdown begins. It acts as barrier
between the time the system is fully up and running and where it is about to shut down. (This extension
happens when <filename>systemd-pcrphase.service</filename> is stopped.)</para></listitem>
<listitem><para><literal>final</literal> — at the end of system shutdown. It acts as barrier between
the time the service manager still runs and when it transitions into the final shutdown phase where
service management is not available anymore. (This extension happens when
<filename>systemd-pcrphase-sysinit.service</filename> is stopped.)</para></listitem>
</orderedlist>
<para>During a regular system lifecycle, the strings <literal>enter-initrd</literal> →
<literal>leave-initrd</literal> → <literal>sysinit</literal> → <literal>ready</literal> →
<literal>shutdown</literal> → <literal>final</literal> are extended into PCR 11, one after the
other.</para>
<para>During a regular system lifecycle, PCR 11 is extended with the strings
<literal>enter-initrd</literal>, <literal>leave-initrd</literal>, <literal>sysinit</literal>,
<literal>ready</literal>, <literal>shutdown</literal>, and <literal>final</literal>.</para>
<para>Specific phases of the boot process may be referenced via the series of strings measured, separated
by colons (the "boot path"). For example, the boot path for the regular system runtime is
by colons (the "phase path"). For example, the phase path for the regular system runtime is
<literal>enter-initrd:leave-initrd:sysinit:ready</literal>, while the one for the initrd is just
<literal>enter-initrd</literal>. The boot path for the the boot phase before the initrd, is an empty
string; because that's hard to pass around a single colon (<literal>:</literal>) may be used
instead. Note that the aforementioned six strings are just the default strings and individual systems
might measure other strings at other times, and thus implement different and more fine-grained boot
phases to bind policy to.</para>
<literal>enter-initrd</literal>. The phase path for the boot phase before the initrd is an empty string;
because that's hard to pass around a single colon (<literal>:</literal>) may be used instead. Note that
the aforementioned six strings are just the default strings and individual systems might measure other
strings at other times, and thus implement different and more fine-grained boot phases to bind policy
to.</para>
<para>By binding policy of TPM2 objects to a specific boot path it is possible to restrict access to them
to specific phases of the boot process, for example making it impossible to access the root file system's
encryption key after the system transitioned from the initrd into the host root file system.</para>
<para>By binding policy of TPM2 objects to a specific phase path it is possible to restrict access to
them to specific phases of the boot process, for example making it impossible to access the root file
system's encryption key after the system transitioned from the initrd into the host root file system.
</para>
<para>Use
<citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
pre-calculate expected PCR 11 values for specific boot phases (via the <option>--phase=</option> switch).</para>
pre-calculate expected PCR 11 values for specific boot phases (via the <option>--phase=</option> switch).
</para>
</refsect1>
<refsect1>

4
man/systemd-portabled.service.xml
View File

@@ -35,8 +35,8 @@
<para>Most of <command>systemd-portabled</command>'s functionality is accessible through the
<citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para>
<para>See <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> for details about
the concepts this service implements.</para>
<para>See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>
for details about the concepts this service implements.</para>
</refsect1>
<refsect1>

Some files were not shown because too many files have changed in this diff Show More