Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > We need PCRs to cover at minimum > > 1. Machine firmware > 2. Bootloader(s) > 3. Bootloader configuration > 4. Booted kernel > 5. Booted initrd > 6. Booted cmdline > Item 5 and 6 are a problem, because as mentioned thse are not signed > by the OS vendor with their secureboot key. The PCRs reflect their > contents, but the expected PCR digests will change any time the > initrd/cmdline are updated, meaning the LUKS keys needs to be > re-sealed. One practical approach to this problem is to use > prebuilt unified kernel images, such that the OS vendor's secureboot > signature covers the kernel,initrd and cmdline. Verification now > merely involves checking the PCR for SecureBOot state. The flipside > is that we loose flexibility that exists today with per-host > generated initrd/cmdline. This may matter for some scenarios (bare > metal) but not for others (most VMs). This isn't a grub2 specific problem, but yes - we've discussed how to accomplih signing initrd/cmdline on calls with you before. > Item 3 is a problem. Grub is highly configurable, via grub.conf, and > its contents are tuned for each install. > > This is a really challenging eventlog when trying to validate the PCR > state is matching some expected "known good" state. Given a single > grub.conf, you get both a huge number of entries for every boot, plus > a combinatorial expansion of possible entries that would be considered > valid for a given install over time as kernels and/or grub itself are > updated. A tiny change to the way grub2-mkconfig could result in a > very different PCR eventlog, but which is semantically identical to > what came before. > > Thus any attempt to validate the the grub.conf PCR eventlog, as it > exists in typical distro deployments today, is going to be both > complex and fragile, which is a bad combination. But this is only a problem if you're assuming grub2-mkconfig is nondeterministic, which just isn't the case. I'll grant that the event log isn't terse, but what's valid isn't be hard to precompute. On generally identical systems, what will differ is uuids and partition numbers... which is important information to have logged for booting because it's part of recording *what* was booted. Glibly, if you don't want a config change, don't run grub2-mkconfig :) We don't run mkconfig on the system after install because it doesn't change - it only get run to change something. And if you update configuration, you'd want to know that things changed - that's the whole point of logging it. Be well, --Robbie
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, report it: https://pagure.io/fedora-infrastructure/new_issue
