On Thu, Feb 6, 2020 at 12:07 AM Anthony DeRobertis <anth...@derobert.net> wrote: > > An interesting challenge you've taken up, I fear it's going to be a lot > of work.
Heh. It's work we're doing internally, so it'd be good to get it into an upstream-acceptable form. > On almost all of my older installs, the initramfs is built with > MODULES=dep, because otherwise /boot runs out of space; the amount of > space MODULES=most takes is ever-increasing. So the kernel packages > plopping a default initramfs in /boot would break those systems (but > that's solvable e.g., by having it be an optional extra binary package) Right. Not everyone is going to care about this use case - I'd just like to enable it. Of course, one approach here would be to provide two images - one with a minimal set of modules suitable for booting most systems, and one with a more complete set of modules. It wouldn't precisely solve the MODULES=dep problem, but it should handle both the common resource constrained case (most desktop and laptop hardware) and the case where you probably aren't too worried about the size of /boot (most servers). > Even with the default, it's possible to include extra modules — either > by the admin plopping them in /etc/initramfs-tools/modules or I believe > through package hooks. (I'm not sure if it also does the work > MODULES=dep does and adds any extra modules found). But maybe as long as > the kernel is only loading signed modules, it's OK to put additional > modules in an extra, non-TPM-measured archive? Yup, that's definitely an option. > /etc/modprobe.d is included in initramfs. That's going to be challenging > because it can include both configuration and code, and even without the > code, "arbitrary kernel modules loaded with arbitrary options" seems to > big a difference to ignore. And you can't not include this, since > initramfs loads so many modules. > > Local udev rules (from /etc/udev/rules.d/) are included as well; they > wind up in /usr/lib/udev/rules.d on the initramfs. Those are again an > interesting combination of configuration and code. I think there's two options here: 1) Rather than copy the files in directly, provide an abstraction that covers the initramfs use cases and generates modprobe.d and udev rules from static configuration, or: 2) As long as these files don't change frequently, this isn't a problem - you can ask the user or admin to verify the files and then flag them as acceptable for future measurements. This is slightly less helpful, but is still an improvement (ie, you're able to figure out /which/ files have changed rather than just knowing that something in the initramfs has changed)
