mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-27 04:03:36 +08:00
Code Issues Packages Projects Releases Wiki Activity
main
systemd/units/systemd-tpm2-setup-early.service.in

27 lines
900 B
SYSTEMD
Raw Permalink Normal View History

tpm2-setup: add new early boot tool for initializing the SRK This adds an explicit service for initializing the TPM2 SRK. This is implicitly also done by systemd-cryptsetup, hence strictly speaking redundant, but doing this early has the benefit that we can parallelize this in a nicer way. This also write a copy of the SRK public key in PEM format to /run/ + /var/lib/, thus pinning the disk image to the TPM. Making the SRK public key is also useful for allowing easy offline encryption for a specific TPM. Sooner or later we should probably grow what this service does, the above is just the first step. For example, the service should probably offer the ability to reset the TPM (clear the owner hierarchy?) on a factory reset, if such a policy is needed. And we might want to install some default AK (?). Fixes: #27986 Also see: #22637
2023-09-27 03:25:53 +08:00
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
units: retitle systemd-pcrextend.{service,socket}, change TPM2→TPM I was looking at the logs in some bug and saw this: Mar 13 15:55:12 fedora systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki). Mar 13 15:55:12 fedora systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems... Mar 13 15:55:12 fedora systemd[1]: systemd-tpm2-setup-early.service - TPM2 SRK Setup (Early) was skipped because of an unmet condition check (ConditionSecurity=measured-uki). This is overly technical, for most units we don't provide this level of detail about the implementation. So retitle the units to be more accessible. Also, the fact that it's a v. 2 of the TPM is not that important. We don't support TPM 1.2, but computers without TPM v2 are getting rare. For other units we don't advertise the version of hardware, and let's not do this here, to reduce some complexity.
2024-03-14 05:18:13 +08:00
Description=Early TPM SRK Setup
tpm2-setup: add new early boot tool for initializing the SRK This adds an explicit service for initializing the TPM2 SRK. This is implicitly also done by systemd-cryptsetup, hence strictly speaking redundant, but doing this early has the benefit that we can parallelize this in a nicer way. This also write a copy of the SRK public key in PEM format to /run/ + /var/lib/, thus pinning the disk image to the TPM. Making the SRK public key is also useful for allowing easy offline encryption for a specific TPM. Sooner or later we should probably grow what this service does, the above is just the first step. For example, the service should probably offer the ability to reset the TPM (clear the owner hierarchy?) on a factory reset, if such a policy is needed. And we might want to install some default AK (?). Fixes: #27986 Also see: #22637
2023-09-27 03:25:53 +08:00
Documentation=man:systemd-tpm2-setup.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
tpm2-setup-early: order against pcrphase-initrd Right now systemd-tpm2-setup-early and systemd-pcrphase-initrd.service are not ordered against each other. However, they require the same slow resource to operate: the TPM2. If we allow them to access the device simultaneously, the kernel resource manager like has to save/restore TPM state while they operate, slowing things down further. hence, let's avoid all this mess, and just order them against each other so that the shared resource is first used in full by one and then by the other. I opted to order systemd-pcrphase-initrd before systemd-tpm2-setup-early, since there's value in having the former as early as possible in userspace, to be a good marker for the transition from kernel to first userspace. I can see no benefit in the opposite order however.
2024-04-22 20:47:58 +08:00
After=tpm2.target systemd-pcrphase-initrd.service
tpm2-setup: add new early boot tool for initializing the SRK This adds an explicit service for initializing the TPM2 SRK. This is implicitly also done by systemd-cryptsetup, hence strictly speaking redundant, but doing this early has the benefit that we can parallelize this in a nicer way. This also write a copy of the SRK public key in PEM format to /run/ + /var/lib/, thus pinning the disk image to the TPM. Making the SRK public key is also useful for allowing easy offline encryption for a specific TPM. Sooner or later we should probably grow what this service does, the above is just the first step. For example, the service should probably offer the ability to reset the TPM (clear the owner hierarchy?) on a factory reset, if such a policy is needed. And we might want to install some default AK (?). Fixes: #27986 Also see: #22637
2023-09-27 03:25:53 +08:00
Before=sysinit.target shutdown.target
ConditionSecurity=measured-uki
ConditionPathExists=!/run/systemd/tpm2-srk-public-key.pem
[Service]
Type=oneshot
RemainAfterExit=yes
tpm2-setup: Add --graceful Currently the associated units fail if full tpm support is not available on the system. Similar to systemd-pcrextend, let's add a --graceful option that exits gracefully if no full TPM support is detected and use it in both units.
2024-03-17 19:34:50 +08:00
ExecStart={{LIBEXECDIR}}/systemd-tpm2-setup --early=yes --graceful
tpm2-setup: Don't fail if we can't access the TPM due to authorization failure The TPM might be password/pin protected for various reasons even if there is no SRK yet. Let's handle those cases gracefully instead of failing the unit as it is enabled by default.
2024-05-17 22:20:11 +08:00
# The tool returns 76 if the TPM cannot be accessed due to an authorization failure and we can't generate an SRK.
SuccessExitStatus=76
Reference in New Issue Copy Permalink