For what is explained on the the systemd-pcrphase.service(8) and
comparing it to what I see in the log of the systemd services, there are
three events in relation to this question:
systemd-pcrphase-initrd.service
[...]
[systemd-ask-password-console.service]
[...]
systemd-pcrphase-sysinit
systemd-pcrphase
This means that, indeed, running cryptenroll after the new kernel has
booted will never provide the correct PCR registry for 11. But then...
what options do I have? Do I need to choose between having PCRs 7 and
14, so that I make sure that SB is up and running and all the certs from
shim have not changed, or to have only PCR 11 so that I know that the
UKI has not changed although SB can potentially be even disabled
(please, correct me if wrong)?
Thank you!
Felix
On 2023-07-05 10:36, Lennart Poettering wrote:
On Mi, 05.07.23 08:30, Felix Rubio (felix@xxxxxxxxx) wrote:
Hi everybody,
In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the
LUKS
drive. Should I use only PCRs 7+14 everything works, but when I add 11
I
need to provide the rescue password every single time I boot.
I have extracted the values of those PCRs using tpm2_pcrread in two
consecutive boots, and they are equal, so at least the issue is
reproducible.
To enroll the PCRs, after a new kernel (and, therefore, the UKI) has
been
generated, I run the following command:
systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
--tpm2-pcrs=7+11+14
<device>
After reading the documentation on systemd-measure (that I am not
using at
the moment): could it be that there are events added to PCR 11 after
the
unlocking has happened, so that I am enrolling the wrong PCR value?
Otherwise... what am I doing wrong?
We mesaure the "boot phase" into PCR 11 too. See
systemd-pcrphase.service(8) for details.
Generally the assumption is that PCR 11 is used for signed PCR
policies, i.e. under vendor control.
Lennart
--
Lennart Poettering, Berlin
