On Thu, Oct 06, 2022 at 01:22:01PM -0400, Robbie Harwood wrote: > 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. Agreed, I just included this to illustrate the overall big picture, not saying this part is grub's problem. > > 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. It is a problem of complexity. On the one side there's a setup where you can pre-compute the PCR state once, and it applies to all instances. On the other side there's a setup where it is neccessary to look at the config to decide where all the instance specific variable data is. If the goal is to always use pre-compute valid data on the attestation service side, it is requried to update it prior to booting any new instance. If the attestation service can be intelligent, it has to be able compute the eventlog against templates with the instance specific pieces masked. Either way is significantly complex, hence the desire to identify a way to eliminate any instance specific variation. > Glibly, if you don't want a config change, don't run grub2-mkconfig :) It isn't solely about predictability within a single install, but about handling validation across a varity of installs running different distros/releases. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
