On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > On Fri, Jul 15, 2022 at 10:33:03AM -0000, Francois Rigault wrote: > > Another idea is to measure the initrd and the boot configuration, for > > example taking a hash of the grub configuration and initrd and > > extending a PCR register. > > That is already happening. > > 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). > > Problem with grub config measurements is that grub measures every config > file line it processes, which is quite messy: 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. I also intend to change sd-stub to measure the kernel it is prefixed to and the other stuff it makes use of from the PE image into a separate PCR, that is otherwise not used so far. i.e. PCR 11 or so. This stuff could then also be easily pre-calculated: if you have the kernel image you know what the PCR value will be. Once we have that, we can relatively easily express policies for TPM resources that bind to kernel + initrd, and pre-calculate those easily at build time (or at install time in case of dynamic initrds), without any need for rebooting into the new setup and then looking at the measured hsah values. 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. The next step is then to extend the kernel PE images, to also contain the PCR hsah signatures appropriate for the kernel. That would make it nice and simple to deploy new kernels in a robust fashion so that they always carry enough metainfo so that TPM policies can be written that match the vendor. (the model isn't perfect yet though: tpm policies built that way need some rollback protection, i.e. some counter kept in tpm nvram that can only increase, and whose cutoff value is also signed along with the PCR hashes, so that one can invalidate old kernels if needed, without having to invalidate signatures as a whole) Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
