linux-kernel - Re: [RFC PATCH] Allow optional module parameters

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]

Date:	Mon, 18 Mar 2013 13:42:23 -0400
From:	Andy Lutomirski <luto@...capital.net>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-kernel@...r.kernel.org,
	Ben Hutchings <bhutchings@...arflare.com>,
	linux-kbuild@...r.kernel.org
Subject: Re: [RFC PATCH] Allow optional module parameters

On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Andy Lutomirski <luto@...capital.net> writes:
>> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>>> Andy Lutomirski <luto@...capital.net> writes:
>>>> Current parameter behavior is odd.  Boot parameters that have values
>>>> and don't match anything become environment variables, with no
>>>> warning.  Boot parameters without values that don't match anything
>>>> go into argv_init.  Everything goes into /proc/cmdline.
>>>>
>>>> The init_module and finit_module syscalls, however, are strict:
>>>> parameters that don't match result in -ENOENT.
>>>>
>>>> kmod (and hence modprobe), when loading a module called foo, look in
>>>> /proc/cmdline for foo.x or foo.x=y, strip off the foo., and pass the
>>>> rest to init_module.
>>>>
>>>> The upshot is that booting with module.nonexistent_parameter=1 is
>>>> okay if module is built in or missing entirely but prevents module
>>>> from loading if it's an actual module.  Similarly, option module
>>>> nonexistent_parameter=1 in /etc/modprobe.d prevents the module from
>>>> loading the parameter goes away.  This means that removing module
>>>> parameters unnecessarily breaks things.
>>>
>>> Err, yes.  Don't remove module parameters, they're part of the API.  Do
>>> you have a particular example?
>>
>> So things like i915.i915_enable_ppgtt, which is there to enable
>> something experimental, needs to stay forever once the relevant
>> feature becomes non-experimental and non-optional?  This seems silly.
>
> Well, it's either experimental, in which case you're happy to break
> users who use it, or it's not, in which case, don't.

Sure.  The main issue for me annoyance.  Install kernel with
experimental option.  Set that option in grub's config.  Boot another
kernel.  Grr, the option got propagated there and now I have no
graphics.

>
>> Having the module parameter go away while still allowing the module to
>> load seems like a good solution (possibly with a warning in the logs
>> so the user can eventually delete the parameter).
>
> Why not do that for *every* missing parameter then?  Why have this weird
> notation where the user must know that the parameter might one day go
> away?

Fair enough.  What about the other approach, then?  Always warn if an
option doesn't match (built-in or otherwise) but load the module
anyways.

--Andy
--
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/