From: Danny Milosavljevic <dannym@scratchpost.org>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Kernel modules in initrd
Date: Fri, 23 Feb 2018 02:00:29 +0100 [thread overview]
Message-ID: <20180223020029.3babc4fa@scratchpost.org> (raw)
In-Reply-To: <87eflck7ko.fsf@netris.org>
Hi Mark,
On Thu, 22 Feb 2018 17:01:11 -0500
Mark H Weaver <mhw@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
next prev parent reply other threads:[~2018-02-23 1:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 21:17 Kernel modules in initrd Andreas Enge
2018-02-22 21:29 ` Jan Nieuwenhuizen
2018-02-22 21:44 ` Danny Milosavljevic
2018-02-22 21:34 ` Danny Milosavljevic
2018-02-22 21:50 ` [PATCH] linux-initrd: Add ATA and SAS modules to the default set of modules Danny Milosavljevic
2018-02-27 15:03 ` Ludovic Courtès
2018-02-22 21:53 ` Kernel modules in initrd Andreas Enge
2018-02-22 22:01 ` Mark H Weaver
2018-02-23 1:00 ` Danny Milosavljevic [this message]
2018-02-23 14:28 ` Danny Milosavljevic
2018-02-23 23:02 ` Andreas Enge
2018-02-25 11:43 ` Danny Milosavljevic
2018-02-26 15:20 ` Ludovic Courtès
2018-02-26 16:26 ` Danny Milosavljevic
2018-02-27 15:02 ` Ludovic Courtès
2018-02-27 19:32 ` Danny Milosavljevic
2018-02-27 20:52 ` Danny Milosavljevic
2018-02-28 21:49 ` Ludovic Courtès
2018-02-23 22:39 ` Ludovic Courtès
2018-02-24 8:28 ` ng0
2018-02-27 15:04 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180223020029.3babc4fa@scratchpost.org \
--to=dannym@scratchpost.org \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.