Hi, > > 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. It might be workable on the installed system, by running grub.cfg through grub shell or something like that. But even that has its challenges, see below. It's next to impossible for a third party though. > On generally identical systems, what will differ is uuids and > partition numbers... Would be nice if it would be that simple. Unfortunately it is not. For starters naming grub.cfg "configuration" is wrong. It's a script language. So grub2 does not measure the configuration, it measures the control flow. Now several features are implemented using the grub script language. Selecting the next kernel to boot via grub2-reboot for example. Also boot counting. So the control flow can be different from boot to boot, depending on how the kernel was picked and what value the boot counter has, leading to different measurements. Also the same config file can lead to different measurements with different grub versions, when the menu entries generated by blscfg change. > 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. So installed systems can have different config files. When the default grub config changes a Fedora N install upgraded to Fedora N+1 will differ from a fresh Fedora N+1 install. > And if you update configuration, you'd want to know that things > changed - that's the whole point of logging it. Depends. Some things clearly matter (root uuid, ...). Some things not so much (menu timeout, menu hidden/shown, ...). take care, Gerd _______________________________________________ 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
