Hi Mark, On Thu, 22 Feb 2018 17:01:11 -0500 Mark H Weaver <m...@netris.org> 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
