On Tue, Jan 21, 2020 at 12:57:50AM +0000, Matthew Garrett wrote: > 2) They contain machine-specific configuration. Some of this can be > passed on the kernel command line instead (eg, the machine ID), but we'd > need answers for the rest. I can think of a couple of solutions: > > a) Stick the config in UEFI variables. It's small enough that we > wouldn't run out. > b) Extend grub to read some config files and synthesise an initramfs > image for them. If we measure the paths that those images use then > we don't need to worry about the contents as long as the tools that > read the config can't be subverted via that configuration. > > 3) User customisation, such as including extra tooling. grub supports > loading multiple initramfs images. Packages that right now install stuff > in the initramfs could instead ship a prebuilt image that grub could > append to the main initramfs. This would allow for things like > overriding Plymouth themes, and we could ship the measurements for these > pre-built images in order to allow them to be validated. > > Any thoughts on this? > Properly measured system must measure all inputs. If you move the varying bits from initramfs to another file, a boot loader will have to measure that another file. At the end that's exactly what GRUB2 does. It measures any loaded file. In my opinon, your proposal does not solve the problem. It actually makes things worse because the booted code would become bigger and probably slower. -- Petr
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
