linux-kernel - Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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:	Wed, 3 Oct 2012 12:07:33 -0700 (PDT)
From:	david@...g.hm
To:	Kees Cook <keescook@...omium.org>
cc:	paulmck@...ux.vnet.ibm.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, 3 Oct 2012, Kees Cook wrote:

>>>> OK, I will bite...  How should I flag an option that is initially only
>>>> intended for those willing to take some level of risk?
>>>
>>> In the text say "You really don't want to enable this option, use at
>>> your own risk!"  Or something like that :)
>>
>> OK, so the only real hope for experimental features is to refrain from
>> creating a config option for them, so that people wishing to use them
>> must modify the code?  Or is the philosophy that we keep things out of
>> tree until we are comfortable with distros turning them on?
>
> I would expect a simple addition of "this is dangerous/buggy" to the
> description and "default n" is likely the way to go for that kind of
> thing. I think the history of CONFIG_EXPERIMENTAL has proven there
> isn't a sensible way to create a global flag for this kind of thing.
> To paraphrase Serge: my experimental options are not your experimental
> options.

Remember that new features/drivers should be defaulting to 'n' in any 
case. It's a rare feature that has no drawbacks (if only in the kernel 
size, which is an issue for small devices). If there really are no 
drawbacks to something, why have it be an option at all?

David Lang
--
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/