> Does it mean that the TPM-awareness of a boot manager is not a must if Secure Boot is enforced?
No. It has nothing to do with Secure Boot. If Secure Boot is not enforced, then we’d just need to verify PCR 4 instead of PCR 7. Secure Boot just makes it simpler because the value of PCR 4 will change everytime we replace the kernel.
The TPM-awareness is not required because the signed kernel + initramfs + cmdline can be executed. An attacker cannot change the behavior of the image being booted (e.g. change the cmdline or initramfs), so we can trust that it won’t do anything insecure with the key (such as printing it out or saving it to a file). If we verify only the kernel, then the initramfs can be modified and an attacker can deploy a new initramfs modified to print out the key.
> If so, how about using a LUKS-aware bootloader that supports decrypting /boot partition (e.g. grub) in order to avoid bothering to create a monolithic EFI binary manually?
I’m not sure if grub supports reading a LUKS key from TPM or not. If it does, then it’s possible. However, you’re increasing your potential surface of attack by having another boot loader.
I use a systemd path unit to re-generate the EFI binary whenever my initramfs change, so it’s fully automatic.
> If Secure Boot is enforced and PCR7 (Secure Boot Status) is validated, it is still necessary to validate PCR4 (Boot Manager)?
You don’t need to validate PCR4 if the following are true:
- Your system firmware varies PCR7 based on the key used to sign the image being booted.
- You are using a self-signed key, so no one else can sign any other binary with the key.
If all above are true, then PCR7 alone is enough to verify that the binary being booted was generated by you.
DISCLAIMER: I am not an expert at cryptography and there may be methods of attacks I did not think of. I highly suggest that you reason for yourself the possible methods of attack rather than take my word for it.
