From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Kernel modules in initrd Date: Fri, 23 Feb 2018 02:00:29 +0100 Message-ID: <20180223020029.3babc4fa@scratchpost.org> References: <20180222211707.GB9758@jurong> <87eflck7ko.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ep1jm-0005GU-2S for guix-devel@gnu.org; Thu, 22 Feb 2018 20:02:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ep1j2-0001EN-PW for guix-devel@gnu.org; Thu, 22 Feb 2018 20:01:21 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:58698) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ep1j2-00019L-BF for guix-devel@gnu.org; Thu, 22 Feb 2018 20:00:36 -0500 In-Reply-To: <87eflck7ko.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, On Thu, 22 Feb 2018 17:01:11 -0500 Mark H Weaver 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 > . 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