[gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

Hi

Some time ago we discussed that we should enable stack smashing 
(-fstack-protector) by default.  So we opened a bug to track this [1].  
The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
ppc64 and arm will be affected by this change. 

You can turn off ssp by using the nossp USE flag or by adding 
-fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
patch as Debian/Ubuntu but with some Gentoo fixes.

The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
it on or off with hardened_gcc_works() that will make some sanity checks.

/Magnus

[-- Attachment #2: toolchin.eclass.patch --]
[-- Type: text/x-patch, Size: 3251 bytes --]

2013-12-31  Magnus Granberg  <zorry@gentoo.org>

	# 484714
	We Add -fstack-protector as default

--- a/eclass/toolchain.eclass	2013-12-30 21:21:05.431832881 +0100
+++ b/eclass/toolchain.eclass	2013-12-31 11:34:00.720993536 +0100
@@ -473,7 +473,9 @@ toolchain_src_prepare() {
 	do_gcc_PIE_patches
 	epatch_user
 
-	use hardened && make_gcc_hard
+	if ( tc_version_is_at_least 4.8 || use hardened ) && ! use vanilla ; then
+		make_gcc_hard
+	fi
 
 	# install the libstdc++ python into the right location
 	# http://gcc.gnu.org/PR51368
@@ -606,6 +608,12 @@ do_gcc_PIE_patches() {
 		epatch "${WORKDIR}"/piepatch/def
 	fi
 
+	BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
+}
+
+# configure to build with the hardened GCC specs as the default
+make_gcc_hard() {
+	
 	# we want to be able to control the pie patch logic via something other
 	# than ALL_CFLAGS...
 	sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
@@ -618,38 +626,38 @@ do_gcc_PIE_patches() {
                         -i "${S}"/gcc/Makefile.in
 	fi
 
-	BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
-}
-
-# configure to build with the hardened GCC specs as the default
-make_gcc_hard() {
-	# defaults to enable for all hardened toolchains
-	local gcc_hard_flags="-DEFAULT_RELRO -DEFAULT_BIND_NOW"
-
-	if hardened_gcc_works ; then
-		einfo "Updating gcc to use automatic PIE + SSP building ..."
-		gcc_hard_flags+=" -DEFAULT_PIE_SSP"
-	elif hardened_gcc_works pie ; then
-		einfo "Updating gcc to use automatic PIE building ..."
-		ewarn "SSP has not been enabled by default"
-		gcc_hard_flags+=" -DEFAULT_PIE"
-	elif hardened_gcc_works ssp ; then
-		einfo "Updating gcc to use automatic SSP building ..."
-		ewarn "PIE has not been enabled by default"
-		gcc_hard_flags+=" -DEFAULT_SSP"
+	# defaults to enable for all toolchains
+	local gcc_hard_flags=""
+	if use hardened ; then
+		if hardened_gcc_works ; then
+			einfo "Updating gcc to use automatic PIE + SSP building ..."
+			gcc_hard_flags+=" -DEFAULT_PIE_SSP"
+		elif hardened_gcc_works pie ; then
+			einfo "Updating gcc to use automatic PIE building ..."
+			ewarn "SSP has not been enabled by default"
+			gcc_hard_flags+=" -DEFAULT_PIE"
+		elif hardened_gcc_works ssp ; then
+			einfo "Updating gcc to use automatic SSP building ..."
+			ewarn "PIE has not been enabled by default"
+			gcc_hard_flags+=" -DEFAULT_SSP"
+		else
+			# do nothing if hardened is't supported, but don't die either
+			ewarn "hardened is not supported for this arch in this gcc version"
+			return 0
+		fi
+		# rebrand to make bug reports easier
+		BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
 	else
-		# do nothing if hardened isnt supported, but dont die either
-		ewarn "hardened is not supported for this arch in this gcc version"
-		ebeep
-		return 0
+		if hardened_gcc_works ssp ; then
+			einfo "Updating gcc to use automatic SSP building ..."
+			gcc_hard_flags+=" -DEFAULT_SSP"
+		fi
 	fi
 
 	sed -i \
 		-e "/^HARD_CFLAGS = /s|=|= ${gcc_hard_flags} |" \
 		"${S}"/gcc/Makefile.in || die
 
-	# rebrand to make bug reports easier
-	BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
 }
 
 # This is a historical wart.  The original Gentoo/amd64 port used:

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 03:58 PM, Magnus Granberg wrote:
> Hi
> 
> Some time ago we discussed that we should enable stack smashing 
> (-fstack-protector) by default.  So we opened a bug to track this [1].  
> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
> ppc64 and arm will be affected by this change. 
> 
> You can turn off ssp by using the nossp USE flag or by adding 
> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
> patch as Debian/Ubuntu but with some Gentoo fixes.

Please avoid "noblah" use flags.

http://devmanual.gentoo.org/general-concepts/use-flags/

ssp flag that defaults to on is fine.

Thanks,
Zero

> 
> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
> it on or off with hardened_gcc_works() that will make some sanity checks.
> 
> /Magnus
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzxCAAAoJEKXdFCfdEflKohoP/iDVryOAlunTvMtrhHYlZAXn
LTPbJRNMQ9bJB8bAd9ECRJ8Q92pAyQt+NyNgUFLtatI+UuiZM6t+dz4K0LcmMQka
n5i6ILdJ14V0BRLGhRz+Xa0ZjpnYRJjCAWrFENTDY6wHc5ni0hSb32xBg84L6j/3
HzNFIWnQOp9dw3hH5OPNQrPXndPVYZMjYTfIADSGx8/4dL9A0GWPY6AXOz08NwuC
oC+zkQi2xSXCb7eHTfkKcIW0TIOF7mFp8Z5LsdW5dm/8nCCLDVH7yxmxVyymyMpb
RnraqCghiv5WOJVsysgivtNPzBwR3ATrNk4dl2qigZSGpJcDEgF2AtSv+YAVb1Ux
wcGOJ5ZJizkMBdAo2pqUBeekXPT/LLWg1EtRvhFI3OLInhbwaHaF9kMWEmhwq2d9
sX6ZfoCmtvn4ZtG3fL++RqyK5QevKOXFCtN2pK9DVMjjgHgp6OtnmVXVCMuZTztI
uqI3XGVvDc0dNIwgxI6KIEfV4/S05Q599hLI49YJVniPknp+sUnsYIdQ+mKztwDf
XON5Fq/Yzt07G1FqZMutEpVMjeTjVckpcLgbFlWz+lO6/xIrqJUgnLUNTXTQf34r
n54Rw+WWIGUWAQqwK3bDh9N2etLzG8p8TqhzEXSCMKXP0sjbX1zzJiYl1roMMpu3
nTFjVJbwpgoaw8OR6FW4
=tSUd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Thu, Jan 09, 2014 at 04:11:28PM -0500, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/09/2014 03:58 PM, Magnus Granberg wrote:
> > Hi
> > 
> > Some time ago we discussed that we should enable stack smashing 
> > (-fstack-protector) by default.  So we opened a bug to track this [1].  
> > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
> > ppc64 and arm will be affected by this change. 
> > 
> > You can turn off ssp by using the nossp USE flag or by adding 
> > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
> > patch as Debian/Ubuntu but with some Gentoo fixes.
> 
> Please avoid "noblah" use flags.
> 
> http://devmanual.gentoo.org/general-concepts/use-flags/
> 
> ssp flag that defaults to on is fine.

Agreed; please do not introduce this with a "nossp" use flag.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On Thu, 09 Jan 2014 16:11:28 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/09/2014 03:58 PM, Magnus Granberg wrote:
> > Hi
> > 
> > Some time ago we discussed that we should enable stack smashing 
> > (-fstack-protector) by default.  So we opened a bug to track this [1].  
> > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
> > ppc, ppc64 and arm will be affected by this change. 
> > 
> > You can turn off ssp by using the nossp USE flag or by adding 
> > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
> > patch as Debian/Ubuntu but with some Gentoo fixes.
> 
> Please avoid "noblah" use flags.
> 
> http://devmanual.gentoo.org/general-concepts/use-flags/
> 
> ssp flag that defaults to on is fine.

This flag already exists and has always worked this way.  We don't have USE
defaults yet.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 854 bytes --]

Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
>
> > Please avoid "noblah" use flags.
> > 
> > http://devmanual.gentoo.org/general-concepts/use-flags/
> > 
> > ssp flag that defaults to on is fine.
> 
> This flag already exists and has always worked this way. 

"already exists and has always worked this way" is not really a good argument. 
The rest of the tree sticks to guidelines, so why not here?

> We don't have USE defaults yet.

Now if you had said "we can't use USE defaults yet since current ebuilds are 
still at EAPI=0"... that would have been slightly more informative. :)

(Yes I've seen that there is work going on, and I think that's good. Being 
careful when modernizing makes sense here of course.)


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote:
> Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
> >
> > > Please avoid "noblah" use flags.
> > > 
> > > http://devmanual.gentoo.org/general-concepts/use-flags/
> > > 
> > > ssp flag that defaults to on is fine.
> > 
> > This flag already exists and has always worked this way. 
> 
> "already exists and has always worked this way" is not really a good argument. 
> The rest of the tree sticks to guidelines, so why not here?

Agreed again. Saying that something has always worked a certain way in
the past is not justification for keeping it working that way,
especially when there are preferred ways of doing the same thing that
are different.

> > We don't have USE defaults yet.
> 
> Now if you had said "we can't use USE defaults yet since current ebuilds are 
> still at EAPI=0"... that would have been slightly more informative. :)
> 
> (Yes I've seen that there is work going on, and I think that's good. Being 
> careful when modernizing makes sense here of course.)

Right, I thought someone had updated toolchain.eclass to use a modern
eapi, but I hadn't seen any more on that in some time. What's the
latest?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Thu, 9 Jan 2014 17:41:08 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote:
> > Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
> > >
> > > > Please avoid "noblah" use flags.
> > > > 
> > > > http://devmanual.gentoo.org/general-concepts/use-flags/
> > > > 
> > > > ssp flag that defaults to on is fine.
> > > 
> > > This flag already exists and has always worked this way. 
> > 
> > "already exists and has always worked this way" is not really a good
> > argument. The rest of the tree sticks to guidelines, so why not here?
> 
> Agreed again. Saying that something has always worked a certain way in
> the past is not justification for keeping it working that way,
> especially when there are preferred ways of doing the same thing that
> are different.

Sure, I'm just pointing out that nothing is changing here.  It sounded like
people were objecting to the addition of a new no* flag.  I agree we should
change them once we can but that shouldn't block this patch.


> > > We don't have USE defaults yet.
> > 
> > Now if you had said "we can't use USE defaults yet since current ebuilds
> > are still at EAPI=0"... that would have been slightly more informative. :)
> > 
> > (Yes I've seen that there is work going on, and I think that's good. Being 
> > careful when modernizing makes sense here of course.)
> 
> Right, I thought someone had updated toolchain.eclass to use a modern
> eapi, but I hadn't seen any more on that in some time. What's the
> latest?

I did, but I can't start using new features until I bring all the ebuilds up to
a minimum EAPI.  I'm going to start that this weekend.



-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 07:12 PM, Ryan Hill wrote:
> On Thu, 9 Jan 2014 17:41:08 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote:
>>> Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
>>>>
>>>>> Please avoid "noblah" use flags.
>>>>>
>>>>> http://devmanual.gentoo.org/general-concepts/use-flags/
>>>>>
>>>>> ssp flag that defaults to on is fine.
>>>>
>>>> This flag already exists and has always worked this way. 
>>>
>>> "already exists and has always worked this way" is not really a good
>>> argument. The rest of the tree sticks to guidelines, so why not here?
>>
>> Agreed again. Saying that something has always worked a certain way in
>> the past is not justification for keeping it working that way,
>> especially when there are preferred ways of doing the same thing that
>> are different.
> 
> Sure, I'm just pointing out that nothing is changing here.  It sounded like
> people were objecting to the addition of a new no* flag.  I agree we should
> change them once we can but that shouldn't block this patch.

To be clear, I don't believe the QA team has any desire to block forward
progress including this patch.
I think everyone is chomping at the bit here to see some improvement on
toolchain getting more up to date, and more with the QA policies that
have been in place for years. I realize eapi 2 wasn't "that long ago"
for some of you, but seriously, it was that long ago.

More to the point, "this specific use flag" appears to have no purpose
what-so-ever.  If a user can do exactly the same with
CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
package to dep on gcc[nossp] then this is has got to be one of the most
useless use flags in gentoo.

Not saying I would block this patch, not saying it has to be this
second, but I see this use flag as a small example of things in
toolchain which could probably be cleaned up if fresh eyes were to see
things.

- -Zero
> 
> 
>>>> We don't have USE defaults yet.
>>>
>>> Now if you had said "we can't use USE defaults yet since current ebuilds
>>> are still at EAPI=0"... that would have been slightly more informative. :)
>>>
>>> (Yes I've seen that there is work going on, and I think that's good. Being 
>>> careful when modernizing makes sense here of course.)
>>
>> Right, I thought someone had updated toolchain.eclass to use a modern
>> eapi, but I hadn't seen any more on that in some time. What's the
>> latest?
> 
> I did, but I can't start using new features until I bring all the ebuilds up to
> a minimum EAPI.  I'm going to start that this weekend.
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSz5SdAAoJEKXdFCfdEflKq6wQAILiZN+BVZh+8XrEBsd4a0om
aOk6Inj4zWMK2y5LvI+T29u1xMvko18lu4Vny4dv13w6OMXsE+nip+1nOhxNyJJG
lCwiVWC603pzYw5am/q/XGg/GncjQFkx3FUSRlM8rJrRCQOyLinronojTtIG0GeV
e4k4eHih+wx73agAHXdvLrXP0Ps11yYxY5+U1Rkjf9p4LwMCtJTAwidm0458YZSp
7+ZYJHiBQvLOpG+evcTx8r+7WqfROjIPpFsCXfuPvZiTbGalXK0hEp1rWZ3aDSsw
wZyjo7cuucTGGDn58QRUIH5KLDZtPC0SVUZl9TVbT+rVbv/ugrboIH2rA33UxYr0
yUFj96gZCgVOHgmxsuOUhiR4R2yIDoFOFg7GEU1TL7ydnqPbxZ9FiYuwOTO5/6oN
hqofWQgC9DgjVDB8V/9m4SON7xZbCsmUhlXM1BCCaDx4HlfsgyHn2QQThRwYM4Oq
HHIA8dCBZytyhlZZ/E8qFlebkbBc7CmsU52htp/iI/eSVMBs7856ljzVbToyY95Q
ClGHIF7zRRWW2tGNo9EurKt+U+esuJS6h2buRwRzWVW8nJYy3z11BnkzGp9vwTAc
1GO3kfruHDTtuvB7esSJAfCdz5WDQ/i7rdj5DkaSISrRL0sIQsgeGPDP2Z7+V4cq
0ItbZIIb/50u8JHNiucS
=lrYq
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Fri, 10 Jan 2014 01:35:09 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> More to the point, "this specific use flag" appears to have no purpose
> what-so-ever.  If a user can do exactly the same with
> CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
> package to dep on gcc[nossp] then this is has got to be one of the most
> useless use flags in gentoo.

Having slept on it I'm starting to agree.  My first argument was that on
hardened ssp is -fstack-protector-all, which is much more expensive, and it
adds -fstack-check and -z,now to the linker by default as well.  The pie half
adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
there are situations where you want to disable one or both, if only for
testing.  But what I forgot is that hardened installs multiple gcc-config
profiles to switch these out on the fly.  So there goes that idea.

It might be useful to have these flags so we can mask them on archs that don't
support ssp/pie.  But that's always been true and it looks like sh is the only
place we've bothered for some reason.

> Not saying I would block this patch, not saying it has to be this
> second, but I see this use flag as a small example of things in
> toolchain which could probably be cleaned up if fresh eyes were to see
> things.

Yes, and believe it or not I appreciate the input.  I know I'm stubborn as hell
but eventually common sense gets through.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/2014 10:50 AM, Ryan Hill wrote:
> On Fri, 10 Jan 2014 01:35:09 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> More to the point, "this specific use flag" appears to have no purpose
>> what-so-ever.  If a user can do exactly the same with
>> CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
>> package to dep on gcc[nossp] then this is has got to be one of the most
>> useless use flags in gentoo.
> 
> Having slept on it I'm starting to agree.  My first argument was that on
> hardened ssp is -fstack-protector-all, which is much more expensive, and it
> adds -fstack-check and -z,now to the linker by default as well.  The pie half
> adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
> there are situations where you want to disable one or both, if only for
> testing.  But what I forgot is that hardened installs multiple gcc-config
> profiles to switch these out on the fly.  So there goes that idea.
> 
> It might be useful to have these flags so we can mask them on archs that don't
> support ssp/pie.  But that's always been true and it looks like sh is the only
> place we've bothered for some reason.
> 
>> Not saying I would block this patch, not saying it has to be this
>> second, but I see this use flag as a small example of things in
>> toolchain which could probably be cleaned up if fresh eyes were to see
>> things.
> 
> Yes, and believe it or not I appreciate the input.  I know I'm stubborn as hell
> but eventually common sense gets through.

Well, that's why I asked for your opinion ;-)  Now since I know you have
plenty to do I'll leave you with this though bouncing around in there.
When you are working on your updates, we would prefer that this "nopie"
and "nossp" flags to bye bye.  If you REALLY wanted a way to change the
gcc profile then do for the normal users what the hardened team does and
offer them multiple profiles.  Obviously we should involved docs team at
that point, but it makes much more sense to "gcc-config 3" than rebuild
gcc with a different use flag.

Again, doesn't have to be this second, but I want it in your head since
I know you are working on this stuff right now.

Thanks!
Zero
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS0D3YAAoJEKXdFCfdEflK1HEP/jdF9nwxpDde8j4PMypeZSm8
FKG0l3MmMr6+2joKkgZSLqVebiTcc8OtCgpk6UJJVEWSpNMWqrjqX5oTkIBAJisr
sGUVGJEAyDCCsNJwTtbW/sBKw5r5Xh1zLk92T55YhaWBMTJPc4UzSqhpr+TBZ8wJ
T77XOIPtxOdZYjubGqIm4lSWsgT/o0F0S6kge75iYm81omuBtZpAze6ePE2DteTj
IinauiMUhqkTYXv6AXdBNv4dDLiInyDrdlUIFbWlawxsx64Wpt77j3jA2fHrRmEf
8MPvoRzLpX/7DPMDaS3WyGBVpM8CPNTaxQiXjC+giXNj4jkJyop/m6Q4a00wYvQg
C+1o6JMEsYNlrIuSooInFxQ5OqARzna4lFc7Jp6+eMaBE4NhYkPkxJ7KOerD3IvI
yW1lSN5gte/zxgm3Ny/96Zw/6+Jx5ffQNc8bCgE2+TxDG0wwB5qZGn/w6dl6gFYX
jXD5dFmw3C5T2HhTIZ6j9n8b0MNkT71CzFA2O4EzEyPrI3b8KTmU6PkppT/Vwlo4
EHc/EUWdjSCPH/FzzJdcNbFUdvLCigZQqvaggN3Qjh/YyJRECXz6Hy2M8VTOg18a
XVE36Z5/DNeobeBQ5XaKLcb5po22wJueJzKFdEK+GaSewzn+FXsNCquVZV9Y3lZC
epKNxmbxtX/Uqx8q9+74
=++P6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/10/2014 10:50 AM, Ryan Hill wrote:
> On Fri, 10 Jan 2014 01:35:09 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
>
>> More to the point, "this specific use flag" appears to have no purpose
>> what-so-ever.  If a user can do exactly the same with
>> CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
>> package to dep on gcc[nossp] then this is has got to be one of the most
>> useless use flags in gentoo.
>
> Having slept on it I'm starting to agree.  My first argument was that on
> hardened ssp is -fstack-protector-all, which is much more expensive, and it
> adds -fstack-check and -z,now to the linker by default as well.  The pie half

I'm pretty sure we're not adding -fstack-check unless something has 
changed.  Where are you seeing that?

The reason I'm concerned is because of situations like bug #471756. 
stack-check incumbers a register which in some situations (like the asm 
in ffmpeg) can get you into trouble with not enough GENERAL_REGS.

> adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
> there are situations where you want to disable one or both, if only for
> testing.  But what I forgot is that hardened installs multiple gcc-config
> profiles to switch these out on the fly.  So there goes that idea.
>
> It might be useful to have these flags so we can mask them on archs that don't
> support ssp/pie.  But that's always been true and it looks like sh is the only
> place we've bothered for some reason.

Yes please.  I had this issue on mips where gcc didn't support ssp for 
early versions of gcc 4.x.

>
>> Not saying I would block this patch, not saying it has to be this
>> second, but I see this use flag as a small example of things in
>> toolchain which could probably be cleaned up if fresh eyes were to see
>> things.
>
> Yes, and believe it or not I appreciate the input.  I know I'm stubborn as hell
> but eventually common sense gets through.
>
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Fri, 10 Jan 2014 15:08:02 -0500
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:

> On 01/10/2014 10:50 AM, Ryan Hill wrote:
> > Having slept on it I'm starting to agree.  My first argument was that on
> > hardened ssp is -fstack-protector-all, which is much more expensive, and it
> > adds -fstack-check and -z,now to the linker by default as well.  The pie
> > half
> 
> I'm pretty sure we're not adding -fstack-check unless something has 
> changed.  Where are you seeing that?
> 
> The reason I'm concerned is because of situations like bug #471756. 
> stack-check incumbers a register which in some situations (like the asm 
> in ffmpeg) can get you into trouble with not enough GENERAL_REGS.

40_all_gcc48_config_esp.patch:

  54 +   #if defined ( EFAULT_SSP ) || defined ( EFAULT_PIE_SSP )
  55 +       #define ESP_OPTIONS_SSP_SPEC \
  56 +           "%{nostdlib|nodefaultlibs|ffreestanding|fno-stack-protector| \
  57 +           fstack-protector|fstack-protector-all:;:-fstack-protector-all} \
  58 +           %{fstack-check|fstack-check=*:;: -fstack-check}"

> > It might be useful to have these flags so we can mask them on archs that
> > don't support ssp/pie.  But that's always been true and it looks like sh is
> > the only place we've bothered for some reason.
> 
> Yes please.  I had this issue on mips where gcc didn't support ssp for 
> early versions of gcc 4.x.

There's a list of arches in every gcc ebuild that support PIE and SSP for
both glibc and uclibc.  AFAICT you would just have to remove mips from that
list.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Pacho Ramos]

El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió:
> Hi
> 
> Some time ago we discussed that we should enable stack smashing 
> (-fstack-protector) by default.  So we opened a bug to track this [1].  
> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
> ppc64 and arm will be affected by this change. 
> 
> You can turn off ssp by using the nossp USE flag or by adding 
> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
> patch as Debian/Ubuntu but with some Gentoo fixes.
> 
> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
> it on or off with hardened_gcc_works() that will make some sanity checks.
> 
> /Magnus

What are the advantages of disabling SSP to deserve that "special"
handling via USE flag or easily disabling it appending the flag? 

Thanks a lot for the info :)

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/09/2014 04:57 PM, Pacho Ramos wrote:
> El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió:
>> Hi
>>
>> Some time ago we discussed that we should enable stack smashing
>> (-fstack-protector) by default.  So we opened a bug to track this [1].
>> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc,
>> ppc64 and arm will be affected by this change.
>>
>> You can turn off ssp by using the nossp USE flag or by adding
>> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
>> patch as Debian/Ubuntu but with some Gentoo fixes.
>>
>> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
>> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
>> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
>> it on or off with hardened_gcc_works() that will make some sanity checks.
>>
>> /Magnus
> What are the advantages of disabling SSP to deserve that "special"
> handling via USE flag or easily disabling it appending the flag?
>
> Thanks a lot for the info :)
>
>

There are some cases where ssp could break things.  I know of once case 
right now, but its somewhat exotic.  Also, sometimes we *want* to break 
things for testing.  I'm thinking here of instance where we want to test 
a pax hardened kernel to see if it catches abuses of memory which would 
otherwise be caught by executables emitted from a hardened toolchain.  
Take a look at the app-admin/paxtest suite.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Pacho Ramos]

El jue, 09-01-2014 a las 17:06 -0500, Anthony G. Basile escribió:
> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
> > El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió:
> >> Hi
> >>
> >> Some time ago we discussed that we should enable stack smashing
> >> (-fstack-protector) by default.  So we opened a bug to track this [1].
> >> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc,
> >> ppc64 and arm will be affected by this change.
> >>
> >> You can turn off ssp by using the nossp USE flag or by adding
> >> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
> >> patch as Debian/Ubuntu but with some Gentoo fixes.
> >>
> >> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
> >> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
> >> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
> >> it on or off with hardened_gcc_works() that will make some sanity checks.
> >>
> >> /Magnus
> > What are the advantages of disabling SSP to deserve that "special"
> > handling via USE flag or easily disabling it appending the flag?
> >
> > Thanks a lot for the info :)
> >
> >
> 
> There are some cases where ssp could break things.  I know of once case 
> right now, but its somewhat exotic.  Also, sometimes we *want* to break 
> things for testing.  I'm thinking here of instance where we want to test 
> a pax hardened kernel to see if it catches abuses of memory which would 
> otherwise be caught by executables emitted from a hardened toolchain.  
> Take a look at the app-admin/paxtest suite.
> 
> 

OK, thanks a lot, I was wondering if I would need to disable SSP on some
of the machines I maintain for some reason. Looks like keeping it
enabled is preferred instead ;)

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Dnia 2014-01-09, o godz. 17:06:52
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
> > What are the advantages of disabling SSP to deserve that "special"
> > handling via USE flag or easily disabling it appending the flag?
> 
> There are some cases where ssp could break things.  I know of once case 
> right now, but its somewhat exotic.  Also, sometimes we *want* to break 
> things for testing.  I'm thinking here of instance where we want to test 
> a pax hardened kernel to see if it catches abuses of memory which would 
> otherwise be caught by executables emitted from a hardened toolchain.  
> Take a look at the app-admin/paxtest suite.

Just to be clear, are we talking about potential system-wide breakage
or single, specific packages being broken by SSP? In other words, are
there cases when people will really want to disable SSP completely?

Unless I'm misunderstanding something, your examples sound like you
just want -fno-stack-protector per-package. I don't really think you
actually want to rebuild whole gcc just to do some testing on a single
package...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 05:21 PM, Michał Górny wrote:
> Dnia 2014-01-09, o godz. 17:06:52
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> 
>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>> What are the advantages of disabling SSP to deserve that "special"
>>> handling via USE flag or easily disabling it appending the flag?
>>
>> There are some cases where ssp could break things.  I know of once case 
>> right now, but its somewhat exotic.  Also, sometimes we *want* to break 
>> things for testing.  I'm thinking here of instance where we want to test 
>> a pax hardened kernel to see if it catches abuses of memory which would 
>> otherwise be caught by executables emitted from a hardened toolchain.  
>> Take a look at the app-admin/paxtest suite.
> 
> Just to be clear, are we talking about potential system-wide breakage
> or single, specific packages being broken by SSP? In other words, are
> there cases when people will really want to disable SSP completely?
> 
> Unless I'm misunderstanding something, your examples sound like you
> just want -fno-stack-protector per-package. I don't really think you
> actually want to rebuild whole gcc just to do some testing on a single
> package...
> 
Or just as easily set -fno-stack-protector in CFLAGS in make.conf.

I never felt manipulating cflags with use flags was a great idea, but in
this case is does feel extra pointless.

Personally I don't feel this is needed, and the added benefit of
clearing up a bogus "noblah" use flag makes me smile.

Zorry, do we really need this flag?

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzyLGAAoJEKXdFCfdEflKo44QAJ4wYfgHdLYffTPaiXZe2ZJn
3jPxaZX47m7BjgdtePZZncClby5h84cG+Jchb0pn/a6K6TknpiFXLQzArsJbMH0N
th7cuuuS4iFQMw2xq8hNAvGAdMF4R0+/OSpBkzlskakcCVRHgV+KCz9llimny4hB
RbTXK9Irva0bwYb5IkmTq+/JVqHjB5DyXUYMu32vdvgz8uxTPXXHHO5HtPlkLeiq
YsumFhnHFb5d+yPvPzZ3YSMJyuHHtBeZFCOJoirtxL08+yr5dZhgppEbqkMJcHIG
r1xKxPqFSmccHSJ8mCZ+l3mvrSL7Akd7D9c7Rk6hZ8RpMQnxCTNb3/Twq6oqAqKm
JfcU1B6rKIDz6eZOtMmVMyVcfnlo7MHO/resmFCS/BYN5AyqyfHgn+I4OU4IVCvQ
2jaZOwxeXGePgkwK37ebK/274N63lSkQAbaB0K43oqvsmtNuq+qZQQEm7jkY+0Vu
SYKc3y4hXeLvexxteiR559fB7zJ1zPIsvvOWrqVP7euYezPMI7cjamz+7VHJYyH4
3RdGpro4Qg7OOTr42naBsWBW20nRTecWpm6kg0jyJo9eSD5YPzLq5r9ITcv7c6mB
/6OxgqbVubzxpo9+kpY/11rEgQx5li4wKbLVsBY3n/f+tDCi1GNTu2k6ottdgrt2
XgsAKT4j/dUq8dhh80P7
=9pZW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/09/2014 05:29 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/09/2014 05:21 PM, Michał Górny wrote:
>> Dnia 2014-01-09, o godz. 17:06:52
>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>
>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>> What are the advantages of disabling SSP to deserve that "special"
>>>> handling via USE flag or easily disabling it appending the flag?
>>> There are some cases where ssp could break things.  I know of once case
>>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>>> things for testing.  I'm thinking here of instance where we want to test
>>> a pax hardened kernel to see if it catches abuses of memory which would
>>> otherwise be caught by executables emitted from a hardened toolchain.
>>> Take a look at the app-admin/paxtest suite.
>> Just to be clear, are we talking about potential system-wide breakage
>> or single, specific packages being broken by SSP? In other words, are
>> there cases when people will really want to disable SSP completely?
>>
>> Unless I'm misunderstanding something, your examples sound like you
>> just want -fno-stack-protector per-package. I don't really think you
>> actually want to rebuild whole gcc just to do some testing on a single
>> package...
>>
> Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
>
> I never felt manipulating cflags with use flags was a great idea, but in
> this case is does feel extra pointless.
>
> Personally I don't feel this is needed, and the added benefit of
> clearing up a bogus "noblah" use flag makes me smile.
>
> Zorry, do we really need this flag?
>
>

toolchain.eclass currently uses nossp as well as nopie.  You'd have to 
rework that to get rid of the flag.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/09/2014 05:29 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/09/2014 05:21 PM, Michał Górny wrote:
>> Dnia 2014-01-09, o godz. 17:06:52
>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>
>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>> What are the advantages of disabling SSP to deserve that "special"
>>>> handling via USE flag or easily disabling it appending the flag?
>>> There are some cases where ssp could break things.  I know of once case
>>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>>> things for testing.  I'm thinking here of instance where we want to test
>>> a pax hardened kernel to see if it catches abuses of memory which would
>>> otherwise be caught by executables emitted from a hardened toolchain.
>>> Take a look at the app-admin/paxtest suite.
>> Just to be clear, are we talking about potential system-wide breakage
>> or single, specific packages being broken by SSP? In other words, are
>> there cases when people will really want to disable SSP completely?
>>
>> Unless I'm misunderstanding something, your examples sound like you
>> just want -fno-stack-protector per-package. I don't really think you
>> actually want to rebuild whole gcc just to do some testing on a single
>> package...
>>
> Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
>

I just reread this and we'd better be clear here.  With ssp on by 
default in gcc, if you put CFLAGS="...  -fno-stack-protector" in 
make.conf you will build your *entire* system with no ssp.  You probably 
don't want this.  You'll probably only want ssp off on a per package 
basis, in which case, add a line to package.env and set the CFLAGS for 
only that package.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 06:09 PM, Anthony G. Basile wrote:
> On 01/09/2014 05:29 PM, Rick "Zero_Chaos" Farina wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/09/2014 05:21 PM, Michał Górny wrote:
>>> Dnia 2014-01-09, o godz. 17:06:52
>>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>>
>>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>>> What are the advantages of disabling SSP to deserve that "special"
>>>>> handling via USE flag or easily disabling it appending the flag?
>>>> There are some cases where ssp could break things.  I know of once case
>>>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>>>> things for testing.  I'm thinking here of instance where we want to
>>>> test
>>>> a pax hardened kernel to see if it catches abuses of memory which would
>>>> otherwise be caught by executables emitted from a hardened toolchain.
>>>> Take a look at the app-admin/paxtest suite.
>>> Just to be clear, are we talking about potential system-wide breakage
>>> or single, specific packages being broken by SSP? In other words, are
>>> there cases when people will really want to disable SSP completely?
>>>
>>> Unless I'm misunderstanding something, your examples sound like you
>>> just want -fno-stack-protector per-package. I don't really think you
>>> actually want to rebuild whole gcc just to do some testing on a single
>>> package...
>>>
>> Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
>>
> 
> I just reread this and we'd better be clear here.  With ssp on by
> default in gcc, if you put CFLAGS="...  -fno-stack-protector" in
> make.conf you will build your *entire* system with no ssp.  You probably
> don't want this.  You'll probably only want ssp off on a per package
> basis, in which case, add a line to package.env and set the CFLAGS for
> only that package.
> 
Of course this is EXACTLY the same as building gcc[nossp] which is what
we are discussing. So afaict you and I are in total agreement on all fronts.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzy6AAAoJEKXdFCfdEflKOY0P/2dfvjVAFTq9NyZqMgJe0j1/
sENGtTCAAxKWh3eoqPywDJpEarPYoIsctMUGbuM2Dx6kC1zv20klXiT9Oec5j8aG
qnAogeCubAQD/AjDLI5VjDU5dAH7xUEEQKWPEEdjqfV1xWstW91f+tfPg2JkxpMS
zeQtSAIhJJMRdcFXmmWIvbh8zAUczdxsEcdGBHSt97utbMnbJMOE1eGEWGqAfzWm
vFYLnA8R/TZO//wkbkqNTAQjL3JV8DKScaqVyFxh5wQhTCLMN4QFVqnlSJGDiZPS
bddylShRtMXXsqPmFmLIsFf9tY7N03+2U8Ex3l1ToEpBATK6kkwBtuVCv0tOPvp8
EYOOXjmHZSmsG37SUFMgZpsAfNCf6H030G1i9NEC2zOnW5i9vHWmL1rAVpVYGdu2
N3rW2QYPEQzIBjNOojsXp515okIzPt8biXcWGT1R+te2BUoEeNwLNco9zCJecL1H
YZNSmmA0fwc/vgvKOh1kfV4VAFwmM/cHAlI7UPG9ypM6Fo/3dn7zZgUaXdQU2KeL
g+UNaFDj2p8ob+2vIc5N0lNwSNgY/vms2DehXRAV52vwogxNBgTftJZwwQv+j25u
g1JWGf/MOXbh7mfDDK5Xr10fHEui6hpeSofC3BZC8pQ6k1duB1rKituWhBzBJBPF
w8AeXL74ZvsUwwUxwi4A
=AtZz
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On Thu, 09 Jan 2014 17:29:26 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/09/2014 05:21 PM, Michał Górny wrote:
> > Dnia 2014-01-09, o godz. 17:06:52
> > "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > 
> >> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
> >>> What are the advantages of disabling SSP to deserve that "special"
> >>> handling via USE flag or easily disabling it appending the flag?
> >>
> >> There are some cases where ssp could break things.  I know of once case 
> >> right now, but its somewhat exotic.  Also, sometimes we *want* to break 
> >> things for testing.  I'm thinking here of instance where we want to test 
> >> a pax hardened kernel to see if it catches abuses of memory which would 
> >> otherwise be caught by executables emitted from a hardened toolchain.  
> >> Take a look at the app-admin/paxtest suite.
> > 
> > Just to be clear, are we talking about potential system-wide breakage
> > or single, specific packages being broken by SSP? In other words, are
> > there cases when people will really want to disable SSP completely?
> > 
> > Unless I'm misunderstanding something, your examples sound like you
> > just want -fno-stack-protector per-package. I don't really think you
> > actually want to rebuild whole gcc just to do some testing on a single
> > package...
> > 
> Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
> 
> I never felt manipulating cflags with use flags was a great idea, but in
> this case is does feel extra pointless.
> 
> Personally I don't feel this is needed, and the added benefit of
> clearing up a bogus "noblah" use flag makes me smile.
> 
> Zorry, do we really need this flag?

Yes, we do.  I want a way to disable it at a toolchain level.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Thu, 9 Jan 2014 17:30:46 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Thu, 09 Jan 2014 17:29:26 -0500
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 01/09/2014 05:21 PM, Michał Górny wrote:
> > > Dnia 2014-01-09, o godz. 17:06:52
> > > "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > > 
> > >> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
> > >>> What are the advantages of disabling SSP to deserve that "special"
> > >>> handling via USE flag or easily disabling it appending the flag?
> > >>
> > >> There are some cases where ssp could break things.  I know of once case 
> > >> right now, but its somewhat exotic.  Also, sometimes we *want* to break 
> > >> things for testing.  I'm thinking here of instance where we want to test 
> > >> a pax hardened kernel to see if it catches abuses of memory which would 
> > >> otherwise be caught by executables emitted from a hardened toolchain.  
> > >> Take a look at the app-admin/paxtest suite.
> > > 
> > > Just to be clear, are we talking about potential system-wide breakage
> > > or single, specific packages being broken by SSP? In other words, are
> > > there cases when people will really want to disable SSP completely?
> > > 
> > > Unless I'm misunderstanding something, your examples sound like you
> > > just want -fno-stack-protector per-package. I don't really think you
> > > actually want to rebuild whole gcc just to do some testing on a single
> > > package...
> > > 
> > Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
> > 
> > I never felt manipulating cflags with use flags was a great idea, but in
> > this case is does feel extra pointless.
> > 
> > Personally I don't feel this is needed, and the added benefit of
> > clearing up a bogus "noblah" use flag makes me smile.
> > 
> > Zorry, do we really need this flag?
> 
> Yes, we do.  I want a way to disable it at a toolchain level.

Let me clarify.  I would like to be able to disable it without relying on
CFLAGS or anything the user could fiddle with.  I need a big red off switch,
at least for now.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 07:17 PM, Ryan Hill wrote:
> On Thu, 9 Jan 2014 17:30:46 -0600 Ryan Hill <dirtyepic@gentoo.org>
> wrote:
> 
>> On Thu, 09 Jan 2014 17:29:26 -0500 "Rick \"Zero_Chaos\" Farina"
>> <zerochaos@gentoo.org> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 01/09/2014 05:21 PM, Michał Górny wrote:
>>>> Dnia 2014-01-09, o godz. 17:06:52 "Anthony G. Basile"
>>>> <blueness@gentoo.org> napisał(a):
>>>> 
>>>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>>>> What are the advantages of disabling SSP to deserve that
>>>>>> "special" handling via USE flag or easily disabling it
>>>>>> appending the flag?
>>>>> 
>>>>> There are some cases where ssp could break things.  I know
>>>>> of once case right now, but its somewhat exotic.  Also,
>>>>> sometimes we *want* to break things for testing.  I'm
>>>>> thinking here of instance where we want to test a pax
>>>>> hardened kernel to see if it catches abuses of memory which
>>>>> would otherwise be caught by executables emitted from a
>>>>> hardened toolchain. Take a look at the app-admin/paxtest
>>>>> suite.
>>>> 
>>>> Just to be clear, are we talking about potential system-wide
>>>> breakage or single, specific packages being broken by SSP? In
>>>> other words, are there cases when people will really want to
>>>> disable SSP completely?
>>>> 
>>>> Unless I'm misunderstanding something, your examples sound
>>>> like you just want -fno-stack-protector per-package. I don't
>>>> really think you actually want to rebuild whole gcc just to
>>>> do some testing on a single package...
>>>> 
>>> Or just as easily set -fno-stack-protector in CFLAGS in
>>> make.conf.
>>> 
>>> I never felt manipulating cflags with use flags was a great
>>> idea, but in this case is does feel extra pointless.
>>> 
>>> Personally I don't feel this is needed, and the added benefit
>>> of clearing up a bogus "noblah" use flag makes me smile.
>>> 
>>> Zorry, do we really need this flag?
>> 
>> Yes, we do.  I want a way to disable it at a toolchain level.
> 
> Let me clarify.  I would like to be able to disable it without
> relying on CFLAGS or anything the user could fiddle with.  I need a
> big red off switch, at least for now.
> 
> 
I think if you clarify this last statement a lot of the arguments will
vanish.  I believe most of us are happy to hear your thoughts in a
little more detail, and will be swayed by them.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSz5W+AAoJEKXdFCfdEflKle4P/3pwjbSDuPy56TXvyH43/Ucg
LvTtyycvGF5pw4UzNBPoao+E7F4E84MFIrfLGE3XpkH1J4v4SLXwh+CuHJHaSxJg
Zx1C6zhk0HnAS2LZHDCuS14+zyOpF/VELOZAimr8V1UBTot3gyZUVvBIsXoJwKx6
3nb+abTHHIFDcSGJz6KM36dy67MMW2kpcKTx5Wu7W91232K8WY3v1KuNRtLBQkd/
/YNcpkW3fkA5Plk7sMTFb8iL6k2oajNw/3PKvX9L/MSBf+PmGKB7yA3Yt5Qu2Grw
gUdUel/fCtXyhv1Had3pjeqZCgK7mFUuw6pAieQen2cYmAypLTC8D7JpaIBkJ9G0
cAz4lBB4EXc+l5mh2SS9D4LqL/4bWu3f7xFdeSuGcoxU1aL8/pgAvz0LpP7/o8ib
BMdvwPcy5zn9W5+jkx5IZXidIpEBHzJKEnSR5+Mf39xn9z0nOrEvzGWxEHIerlWc
hlHNU8x5wsZdnfJsY9tOfb5/hCOZW6uTtdvSR7eDFC6+xx2kBuiS+lC9Dtg76t1q
VAiDOQIb1qgM9D6IUA+Q6WG2sWj3aTmZxfRYYQZ0DBGG266Rr2HaQaVDmWjU8W2u
etxretxm0emYr8vHBPJD1XKwOCs577u4W5sVrQbZl+VutEVH+pqJTg0NOYxTeSTW
CWAZGdV093+dQAa58/M4
=YP+O
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rich Freeman]

On Thu, Jan 9, 2014 at 5:29 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> I never felt manipulating cflags with use flags was a great idea, but in
> this case is does feel extra pointless.
>

Tend to agree, though one place I could see it being hypothetically
useful is if we need to set a use-dep.  That is, package bar might
have a dep on dev-lib/libfoo[-ssp] (or nossp or whatever).

However, what I don't know is whether that will be helpful.  If it is,
then it might make sense to make an exception, otherwise I agree that
overloading CFLAGS in USE flags is bad.

Rich

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Dnia 2014-01-09, o godz. 18:59:26
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Thu, Jan 9, 2014 at 5:29 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
> > I never felt manipulating cflags with use flags was a great idea, but in
> > this case is does feel extra pointless.
> >
> 
> Tend to agree, though one place I could see it being hypothetically
> useful is if we need to set a use-dep.  That is, package bar might
> have a dep on dev-lib/libfoo[-ssp] (or nossp or whatever).
> 
> However, what I don't know is whether that will be helpful.  If it is,
> then it might make sense to make an exception, otherwise I agree that
> overloading CFLAGS in USE flags is bad.

We're talking about the ssp (nossp) flag on gcc, not target ebuilds.
Ebuilds have to do stuff like '-fno-stack-protector'. The flag on gcc
rebuilds whole gcc just to change the global default.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/09/2014 05:21 PM, Michał Górny wrote:
> Dnia 2014-01-09, o godz. 17:06:52
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>
>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>> What are the advantages of disabling SSP to deserve that "special"
>>> handling via USE flag or easily disabling it appending the flag?
>> There are some cases where ssp could break things.  I know of once case
>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>> things for testing.  I'm thinking here of instance where we want to test
>> a pax hardened kernel to see if it catches abuses of memory which would
>> otherwise be caught by executables emitted from a hardened toolchain.
>> Take a look at the app-admin/paxtest suite.
> Just to be clear, are we talking about potential system-wide breakage
> or single, specific packages being broken by SSP? In other words, are
> there cases when people will really want to disable SSP completely?
>
> Unless I'm misunderstanding something, your examples sound like you
> just want -fno-stack-protector per-package. I don't really think you
> actually want to rebuild whole gcc just to do some testing on a single
> package...
>
Correct, you'd only want to turn off ssp per package and then only in 
rare cases.  You should never have to rebuild gcc for this.  With ssp on 
by default, gcc specs would add -fstack-protector to all builds.  If you 
don't want a package build with ssp, then just do 
CFLAGS="-fno-stack-protector" and you're building without ssp.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 06:01 PM, Anthony G. Basile wrote:
> On 01/09/2014 05:21 PM, Michał Górny wrote:
>> Dnia 2014-01-09, o godz. 17:06:52
>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>
>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>> What are the advantages of disabling SSP to deserve that "special"
>>>> handling via USE flag or easily disabling it appending the flag?
>>> There are some cases where ssp could break things.  I know of once case
>>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>>> things for testing.  I'm thinking here of instance where we want to test
>>> a pax hardened kernel to see if it catches abuses of memory which would
>>> otherwise be caught by executables emitted from a hardened toolchain.
>>> Take a look at the app-admin/paxtest suite.
>> Just to be clear, are we talking about potential system-wide breakage
>> or single, specific packages being broken by SSP? In other words, are
>> there cases when people will really want to disable SSP completely?
>>
>> Unless I'm misunderstanding something, your examples sound like you
>> just want -fno-stack-protector per-package. I don't really think you
>> actually want to rebuild whole gcc just to do some testing on a single
>> package...
>>
> Correct, you'd only want to turn off ssp per package and then only in
> rare cases.  You should never have to rebuild gcc for this.  With ssp on
> by default, gcc specs would add -fstack-protector to all builds.  If you
> don't want a package build with ssp, then just do
> CFLAGS="-fno-stack-protector" and you're building without ssp.
> 
This reads very much like "the nossp use flag is useless".

Not that Zorry needs to fix that (preexisting and all that) but it
sounds to me like it's safe to remove these types of use flags from
toolchain.

I'm really interested in dirtyepic's opinion though... sir?

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzy0dAAoJEKXdFCfdEflKZJEP/3P/Gq3sD6aB9XDcsLxUAVqC
vg10PuwhmNpJK6HiYO2F/C5TNv3J+hpkiYPDMgjChOTw+JvqGCeIYYKvKuumtIXV
fjnHDW9IRD8BGHlNFF9xx3sGV9VMPYDNICkK3oeNQJPlZOVSbnVEWsaTju/CEA7e
tMkeA93ULed9pSzSZ3OBAIwLH906Kh8hO+o/gcJDyBa9/tJrXKfS+jtd6zTMbVtO
8ruLjRUDTsYwt61uMFhV7R/eWlSagGIFDGbxop0JyhTZaB+zxvbm8wzmZck4Tc2J
HFO4A289zFBVZESaDA4SHAYJHQTSMND1fzAB8X4sPEwNebmLwOinneuA7XYVRsHW
svu/I3tUPjNTKimTSmjMySi7f+3QDYLIxQ8UY0PUCPKjdlNZMQruqCR52lTsjy8F
n0EpLMqodD61B+aCkkBpdrt1sx/BJ4AISq8R51yiJecujPoSk1oj5gG1aFOPK/mG
BIQqLL1c6TvbB4ECLVMh6YAfxRKcyCT8tlMZqu2rTRqtxQ+YlUnxwvIQV7ivQ5sL
M8eC/HjVjd0In9v5GVxePa3NFfwwuswnFipi2mivniajmZYi8M8avSVLpv54Kvi0
cAysdf/FP4WA+iVCd5J+MKGygKKSmbyYZ9IHyE4yCyCNK+0+ZZcFm9YNy9nx8rAJ
4ctTVxoCTtA+B9p3MBnL
=6a0w
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Anthony G. Basile]

On 01/09/2014 06:13 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/09/2014 06:01 PM, Anthony G. Basile wrote:
>> On 01/09/2014 05:21 PM, Michał Górny wrote:
>>> Dnia 2014-01-09, o godz. 17:06:52
>>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>>
>>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote:
>>>>> What are the advantages of disabling SSP to deserve that "special"
>>>>> handling via USE flag or easily disabling it appending the flag?
>>>> There are some cases where ssp could break things.  I know of once case
>>>> right now, but its somewhat exotic.  Also, sometimes we *want* to break
>>>> things for testing.  I'm thinking here of instance where we want to test
>>>> a pax hardened kernel to see if it catches abuses of memory which would
>>>> otherwise be caught by executables emitted from a hardened toolchain.
>>>> Take a look at the app-admin/paxtest suite.
>>> Just to be clear, are we talking about potential system-wide breakage
>>> or single, specific packages being broken by SSP? In other words, are
>>> there cases when people will really want to disable SSP completely?
>>>
>>> Unless I'm misunderstanding something, your examples sound like you
>>> just want -fno-stack-protector per-package. I don't really think you
>>> actually want to rebuild whole gcc just to do some testing on a single
>>> package...
>>>
>> Correct, you'd only want to turn off ssp per package and then only in
>> rare cases.  You should never have to rebuild gcc for this.  With ssp on
>> by default, gcc specs would add -fstack-protector to all builds.  If you
>> don't want a package build with ssp, then just do
>> CFLAGS="-fno-stack-protector" and you're building without ssp.
>>
> This reads very much like "the nossp use flag is useless".
>
I was not referring to the nossp flag.  I was simply answering Michał's 
concern about ssp and system wide breakage.  My point is that ssp on by 
default will NOT lead to system wide breakage, only per package and then 
only very very rarely.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

torsdag 09 januari 2014 22.57.09 skrev  Pacho Ramos:
> El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió:
> > Hi
> > 
> > Some time ago we discussed that we should enable stack smashing
> > (-fstack-protector) by default.  So we opened a bug to track this [1].
> > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
> > ppc, ppc64 and arm will be affected by this change.
> > 
> > You can turn off ssp by using the nossp USE flag or by adding
> > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
> > patch as Debian/Ubuntu but with some Gentoo fixes.
> > 
> > The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
> > ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
> > make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
> > it on or off with hardened_gcc_works() that will make some sanity checks.
> > 
> > /Magnus
> 
> What are the advantages of disabling SSP to deserve that "special"
> handling via USE flag or easily disabling it appending the flag?
> 
> Thanks a lot for the info :)

If you want Gcc not to build stuff with ssp as default you turn on the nossp 
flag and rebuild Gcc.

/Magnus

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Thu, 09 Jan 2014 21:58:46 +0100
Magnus Granberg <zorry@gentoo.org> wrote:

> -	use hardened && make_gcc_hard
> +	if ( tc_version_is_at_least 4.8 || use hardened ) && ! use vanilla ; then

s/4.8/4.8.2

Or should we wait until the next release (4.8.3 or 4.9.0)?  I think I'd
prefer it but I don't have a good reason.

What gcc-config profiles get installed after this patch?


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

torsdag 09 januari 2014 17.56.56 skrev  Ryan Hill:
> On Thu, 09 Jan 2014 21:58:46 +0100
> 
> Magnus Granberg <zorry@gentoo.org> wrote:
> > -	use hardened && make_gcc_hard
> > +	if ( tc_version_is_at_least 4.8 || use hardened ) && ! use vanilla ;
> > then
> 
> s/4.8/4.8.2
> 
> Or should we wait until the next release (4.8.3 or 4.9.0)?  I think I'd
> prefer it but I don't have a good reason.
> 
> What gcc-config profiles get installed after this patch?
We have only one now. But we can add a nossp but
i would only use it for debuging and it don't mix well with distcc.
The GCC_SPECS is not trasfered betvine the host and guest.

/Magnus


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Thu, 09 Jan 2014 21:58:46 +0100
Magnus Granberg <zorry@gentoo.org> wrote:

> Some time ago we discussed that we should enable stack smashing 
> (-fstack-protector) by default.  So we opened a bug to track this [1].  
> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
> ppc64 and arm will be affected by this change. 
> 
> You can turn off ssp by using the nossp USE flag or by adding 
> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
> patch as Debian/Ubuntu but with some Gentoo fixes.
> 
> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
> it on or off with hardened_gcc_works() that will make some sanity checks.

I went ahead and spun a new patchset for the compiler-side stuff if anyone
wants to start playing around.

- apply the eclass patch from bug #484714 (the one attached to Magnus' email
  wouldn't apply for me but maybe my mailer mangled it)
- in gcc-4.8.2.ebuild do:

-PATCH_VER="1.3"
+PATCH_VER="1.4-ssptest"
 
-PIE_VER="0.5.8"
+PIE_VER="0.5.9-ssptest"

BTW Magnus, thanks for doing this.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

torsdag 09 januari 2014 23.18.28 skrev  Ryan Hill:
> On Thu, 09 Jan 2014 21:58:46 +0100
> 
> Magnus Granberg <zorry@gentoo.org> wrote:
> > Some time ago we discussed that we should enable stack smashing
> > (-fstack-protector) by default.  So we opened a bug to track this [1].
> > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
> > ppc, ppc64 and arm will be affected by this change.
> > 
> > You can turn off ssp by using the nossp USE flag or by adding
> > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
> > patch as Debian/Ubuntu but with some Gentoo fixes.
> > 
> > The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
> > ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
> > make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
> > it on or off with hardened_gcc_works() that will make some sanity checks.
> 
> I went ahead and spun a new patchset for the compiler-side stuff if anyone
> wants to start playing around.
> 
> - apply the eclass patch from bug #484714 (the one attached to Magnus' email
> wouldn't apply for me but maybe my mailer mangled it)
> - in gcc-4.8.2.ebuild do:
> 
> -PATCH_VER="1.3"
> +PATCH_VER="1.4-ssptest"
> 
> -PIE_VER="0.5.8"
> +PIE_VER="0.5.9-ssptest"
> 
> BTW Magnus, thanks for doing this.
Hi
Have patched toolchain.eclass with the patch and with your change.
Updated 4.8.2 updated with the needed changes and commit it.
The use hardened && gcc-specs-ssp && append-cflags $(test-flags-CC -fno-stack-
protector) in glibc's common.eblit is fixed to.
So default ssp is out in the tree :)
/Magnus


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Fri, 10 Jan 2014 16:24:38 +0100
Magnus Granberg <zorry@gentoo.org> wrote:

> Hi
> Have patched toolchain.eclass with the patch and with your change.
> Updated 4.8.2 updated with the needed changes and commit it.
> The use hardened && gcc-specs-ssp && append-cflags $(test-flags-CC -fno-stack-
> protector) in glibc's common.eblit is fixed to.

Cool, I forgot about that. ;)

> So default ssp is out in the tree :)

FYI it's masked for testing for now.  I will send out a news item
soon.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]