On Wed, Jul 20, 2022 at 03:06:46PM -0400, Demi Marie Obenour wrote: > On 7/19/22 12:13, Lennart Poettering wrote: > > On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > > > >>> 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. > > > > Yupp. > > > > Zbigniew and I are working on making pre-built initrds for general > > purpose distros a reality, i.e. finding a way between keeping things > > reasonably modular but also pre-generated, immutable, pre-measurable, > > and thus have a tight trust chain at boot. We'll do two talks about > > that at Linux Plumbers Conference later this year. > > > > Lennart > > I wonder if Qubes OS could use any of this work. It seems that it > would be incredibly useful, at least if it supported systems using > the Xen hypervisor. That's probably going to be useful for Qubes OS too, indeed. It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
