On Mon, Jul 18, 2022 at 05:03:53PM +0200, Lennart Poettering wrote:
On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel@redhat.com) wrote:
Problem with measuring the initrd is that we don't have fixed hashes for a given kernel version (due to generating the initrd on the installed system).
The very newest kernels measure all initrds on their own into PCR 9 these days. It should be the only thing measured into PCR 9, hence you can pre-calculate what you are going to see in the PCR easily if you have the initrds.
That is the big if. If you have the initrds.
I've hacked up the kernel rpm to also build a initrd (targeting virtual machines for starters) and shipping that as (optional) sub-rpm ...
https://src.fedoraproject.org/fork/kraxel/rpms/kernel/commits/initrd (proof-of-concept local builds only so far, probably needs fixes for build dependencies to actually work in koji).
... exactly to address that. Known initrd with known hashes, to allow pre-calculating the PCR values.
at build time (or at install time in case of dynamic initrds), without
At build time is much better IMHO. It's more robust. It's easier to manage. The PCR values are useful for third parties (for example remote attestation services) because all machines with a given kernel version run the same initrd.
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
take care, Gerd