Re: Kernel modules in initrd

[Danny Milosavljevic]

Hi Mark,

On Thu, 22 Feb 2018 17:01:11 -0500
Mark H Weaver <address@hidden> wrote:

> Every extra loaded kernel module means more RAM usage in the kernel, a
> larger initrd image that must be loaded by possibly slow bootloaders,
> and code complexity in the running kernel, leading to a greater attack
> surface for possible security exploits.  For example, last year some
> memory corruption bugs were found in the LSI MegaRAID SAS module.  See
> <https://patchwork.kernel.org/patch/9585337/>.

Good points.

> To make this easier, I think the right approach is to include many
> modules like these to our installation image initrd, and then to
> automatically detect which modules are needed for booting.  A future
> easy installer could automatically add those modules to the OS config,
> but in the meantime we could simply print a message recommending that
> the user should add the needed modules to their initrd config.

Good idea.

Another possibility that maybe would make the current situation less bad
would be to put udev-static into the initrd [1] and basically make it only
load the required modules on demand.

Also, udev uses a lot of tools like grep etc - we could use busybox to
get the size of the initrd down again then.

I definitely agree that we should only add modules possibly required for
early booting (until the rootfs is mounted) and not all the modules - that
would be insanely big.

On another note, let's please make the error detection and reporting better.

It should be easy to find unclaimed nodes by scanning /sys/class/pci_bus or
walking /sys/devices/pci0000:00, 
trying to find whether each has a "driver" entry and that would have caught
this problem and improved the diagnostics a lot.  This is not 1990 where
when we had no driver we didn't know the hardware was there.  We do know now.

[1] https://www.redhat.com/archives/fedora-devel-list/2004-May/msg01008.html