linux-kernel - Re: [RFC] [PATCH] Allow overriding module parameters from kernel command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17958.40945.937891.44930@notabene.brown>
Date:	Thu, 19 Apr 2007 08:47:13 +1000
From:	Neil Brown <neilb@...e.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kyle McMartin <kyle@...onical.com>, linux-kernel@...r.kernel.org,
	alan@...hat.com, bcollins@...ntu.com
Subject: Re: [RFC] [PATCH] Allow overriding module parameters from kernel
 command_line

On Wednesday April 18, akpm@...ux-foundation.org wrote:
> > On Wed, 18 Apr 2007 11:55:52 -0400 Kyle McMartin <kyle@...onical.com> wrote:
> > With the move to initramfs and heavily modular configs, which include
> > loading storage drivers from early userspace, it's becoming harder
> > to provide users with a way of overriding module parameters at boot.
> > 
> > Currently, users would have to break into the initramfs, edit the
> > modprobe options, and then let boot continue. They have a much easier time
> > dealing with adding options on the command line from Grub or what have you.
> > 
> > I hacked out this patch quickly to re-parse saved_command_line[] when we
> > load a module in an attempt to rectify this.
> > 
> > (The specific use-case I was looking at here was HPA commands failing on
> >  sata_nv controllers, and needing to pass the adma=0 option to the module...
> >  Users had a hard time testing without an easy way of overriding the module.)
> > 
> > Clearly this is not entirely optimal, because we're parsing command_line
> > after the module params are parsed. This ends of being a policy decision,
> > whether the /sbin/modprobe commandline should override the kernel
> > command_line, or vice versa.
> 
> Similar-but-different: I was trying to persuade a Fedora system to use ext2
> for the root filesystem the other day.  Turns out that we somehow managed
> to break `rootfstype=' in this situation and it cheerfully continued to use
> ext3.
> 
> Fixed by changing /etc/fstab and rebuilding initrd, but IMO rootfstype=
> should have worked.

I think these are both issues that should be solved by smarts in the
initrd.

All of the (unused) kernel parameters are in the environment aren't
they? (if not, they can easily be put there).

So maybe insmod/modprobe could be updated to extract relevant options
from the environment.
And the mount of the root filesystem should be called as:

    mount ${rootfstype+-t $rootfstype} $dev $mountpoint

We are depending more and more on initrd and I think it hurts not
having a reference implementation.
Currently each distro makes their own and while I'm sure they are all
quite good in their own way, the fact that they are independent makes
community input harder.

What we really need is a single reference implementation of "mkinitrd"
which each distro can fiddle with to their heart's content.  Then
sensible ideas like the above can be incorporated into the reference,
and all distros will ultimately pick them up.

But unfortunately I don't have the time to volunteer for this role...

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/