-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/9/12 10:37 AM, Jean Delvare wrote:
Le mardi 03 juillet 2012 à 09:38 +0200, Jean Delvare a écrit :
Le lundi 02 juillet 2012 à 00:37 +0200, Marcus Meissner a écrit :
On Sat, Jun 30, 2012 at 07:05:20PM +0200, richard -rw- weinberger wrote:
Hi!
I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default.
What's the deal?
We had it enabled once, but in the CONFIG_CC_STACKPROTECTOR_ALL mode, which caused speed regressions.
Solution apparently was to disable it completely.
Meanwhile, upstream killed CONFIG_CC_STACKPROTECTOR_ALL. It happened in kernel 2.6.32 with comment:
x86: Remove STACKPROTECTOR_ALL
STACKPROTECTOR_ALL has a really high overhead (runtime and stack footprint) and is not really worth it protection wise (the normal STACKPROTECTOR is in effect for all functions with buffers already), so lets just remove the option entirely.
I think we can enable the non-all version without speed-loss.
I am worried that the option is still marked as experimental, but maybe it was just overlooked. I'll bring the topic up for upstream discussion.
Result from upstream discussion is that CC_STACKPROTECTOR is no longer considered an experimental feature on x86.
That being said, we already have CONFIG_CC_STACKPROTECTOR=y in debug kernels. This led me to investigating the reasons and I found this commit:
commit b4df61d63c69c3d83b5dbf8a9929d9a5022a4027 Author: Nick Piggin <npiggin@suse.de> Date: Tue Nov 10 16:24:00 2009 +1100
- Update config files. Disable CONFIG_CC_STACKPROTECTOR on all x86 kernels except debug. Overhead is prohibitive.
So it was done on purpose. And the interesting detail is that CONFIG_CC_STACKPROTECTOR_ALL had already been dropped at that time. That was recent though (3 weeks), so it's not clear to me if Nick had tested with or without CONFIG_CC_STACKPROTECTOR_ALL.
OTOH Arjan van de Ven just confirmed on LKML that CONFIG_CC_STACKPROTECTOR had been enabled on distribution kernels for years, so I presume the performance issues are history now, and we can do the same in all our kernels.
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore. openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP+u5OAAoJEB57S2MheeWyKfkP/29kJnAbfxxo5swkwHuok5Ak ayEa/arQ8QxKHsgeOsFBu/1oXlhqIDHImw4A6qJALP7881GP1O7sp7ICgaxWgwuO FhmHxy0UDS07rfiTuU6VHRK25022ZJgeLR2YHaU0oEsiVRX6IzJ9BN/VqYGzXeHA RAlBhSts42aQ5loql6MdMmO/ae4sm0ses8Vh85xROyEjssLNn6fP7t5lweVPuKCa H7rXq1nr1mRSKgYJXqkes1Ksjc2oP9esXMW/R50A2YRU1kBdf6BPsnMcz20MNQCw BusJslHd6dYoH3lSPD+cyi3IdDDKWNEQbZKlZ8KQbN0v8pJ4bUm7VdfBLlPP3SeQ s/gKIjFUOr1Rsy163pWcwiWXoIg7obTt0BJ3FzBxKevng5hADvo0NNo2zd/MlSBG MDDTVAsg6ojn4Y2czxsyMfF9/4NPtJ7xFiCEftqmeUu8pSf2BcQhaSZXUOktXOm1 GJLCpjl5+B52ajiXuqjGT5jwC1ZGAyoFYxyOIgnqoNOcwL7eCwJV+ZrSiIzT6IdI zQ5vOH3np1gs6Z7I2PPvY/OR9LKk0hJ84nTDI1y5xFpfp/BtkXbeyXrUoqpvJMjf Sepkf1d0w5+2zhoIXu/kqULrvBGH9Rx2nuPY2CE7MIHAGEZmCTay0kyRe/CJPU8T /9NpHcSWl2J7o/XQKuG0 =362Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org