On Thu, Feb 6, 2020 at 12:07 AM Anthony DeRobertis 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)
