linux-kernel - Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1341820572.4605.35.camel@amber.site>
Date:	Mon, 09 Jul 2012 09:56:12 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

Hi all,

Le vendredi 06 juillet 2012 à 22:19 +0200, Paul Bolle a écrit :
> On Fri, 2012-07-06 at 10:58 -0700, Arjan van de Ven wrote:
> > I rather just retire the whole concept of "Experimental".
> > 
> > it's really utterly meaningless in practice anyway.
> 
> See Russell King's quick survey in https://lkml.org/lkml/2012/1/18/397 :
> almost all defconfigs had CONFIG_EXPERIMENTAL enabled. I didn't recheck
> since I'm sure little has changed. That macro and the related Kconfig
> symbol seem indeed meaningless.

I admit I have CONFIG_EXPERIMENTAL enabled on all my systems as well,
even the ones running an enterprise grade flavor of GNU/Linux.

This isn't necessarily surprising. Having to make decisions at build
time has always been an issue for distributions. The proper way for
distributions to deal with experimental drivers is to package them
separately and/or blacklist them by default. For experimental options,
best is to make them tunable at run time, for example using module
parameters.

As for options still depending on EXPERIMENTAL when they no longer
should, this can partly be explained when the EXPERIMENTAL dependency
doesn't show up in the short description. This is the case of
CONFIG_CC_STACKPROTECTOR. As everybody has CONFIG_EXPERIMENTAL enabled,
nobody notices the dependency.

The existence of CONFIG_EXPERIMENTAL may give developers the impression
that depending on it is sufficient and the right thing to do for
experimental drivers/features. That would be true if depending on
CONFIG_EXPERIMENTAL would automatically add "(EXPERIMENTAL)" to the
short description, as Randy and I were discussing previously, but this
was never implemented.

If we all agree that CONFIG_EXPERIMENTAL is no longer a good idea, then
I'm fine dropping it. I'm always happy to see kernel configuration
options go. Then options which used to depend on it and did not have
"(EXPERIMENTAL)" in their short description should have it appended.
These options should also default to N (but I think this is the default
default if none is specified?) Maybe a task for kernel janitors?

Back to my initial question, am I right to assume that
CONFIG_CC_STACKPROTECTOR is no longer experimental and can be enabled in
distribution kernels?

Thanks,
-- 
Jean Delvare
Suse L3

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