Hi everybody,
Some months ago I tried to learn about systemd cryptenroll, ukify, etc.,
and I managed to get a UKI that gets updated every time the kernel /
modules change by running:
######
/usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd
/boot/amd-ucode.img --initrd /boot/initramfs-linux.img \
--os-release=@$OSRELEASE \
--cmdline="$CMDLINE" \
--secureboot-certificate=/root/SecureBoot/MOK.crt
--secureboot-private-key=/root/SecureBoot/MOK.key \
--output=$OUTPUTPATH/$UKIFILE build
######
To set up the unlock of the disk, I ran the following command (only
once, as pcrs 7 and 14 have not changed since then):
systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+14
/dev/nvme0n1p5
Since then, systemd-cryptenroll has been extended so that literal values
can be provided, meaning that (*I think*) I can upgrade my previous
process to:
######
PCR11=$(/usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd
/boot/amd-ucode.img --initrd /boot/initramfs-linux.img \
--os-release=@$OSRELEASE \
--cmdline="$CMDLINE" \
--secureboot-certificate=/root/SecureBoot/MOK.crt
--secureboot-private-key=/root/SecureBoot/MOK.key \
--measure \
--phases="enter-initrd" \
--pcr-private-key=/root/SecureBoot/PCRsigning/tpm2-pcr-private.pem \
--pcr-public-key=/root/SecureBoot/PCRsigning/tpm2-pcr-public.pem \
--output=$OUTPUTPATH/$UKIFILE build | grep
11:sha256)
systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
--tpm2-pcrs=7+$PCR11+14 /dev/nvme0n1p5
######
Do you guys think this is a sensible approach? As I want to bind the
unlock of the disk to PCR11, I think I only need to get the measurement
of that PCR register in the "enter-initrd" phase, right? What are the
implications of providing as well the pcr-private-key parameter? I have
gone through the documentation of systemd-cryptenroll, systemd-measure
and systemd's ukify, but is not clear to me if this set of flags will
(besides providing the measurement I am interested on) also let the
kernel continue booting only if the signed policy that gets calculated
out of that register is fulfilled. Should that be the case, this
additional control will not harm but I guess is a bit redundant for my
use case?
Thank you very much for your time,
--
Felix Rubio
"Don't believe what you're told. Double check."
