From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-64181-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3A8FD138247 for <garchives@archives.gentoo.org>; Fri, 10 Jan 2014 06:39:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9D90E0D25; Fri, 10 Jan 2014 06:39:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B0E74E0CD1 for <gentoo-dev@lists.gentoo.org>; Fri, 10 Jan 2014 06:39:41 +0000 (UTC) Received: from [192.168.1.17] (pool-72-95-221-222.pitbpa.fios.verizon.net [72.95.221.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id D574F33D8A5 for <gentoo-dev@lists.gentoo.org>; Fri, 10 Jan 2014 06:39:40 +0000 (UTC) Message-ID: <52CF95BE.8060904@gentoo.org> Date: Fri, 10 Jan 2014 01:39:58 -0500 From: "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes. References: <7554031.Sacz2dxc8i@laptop1.gw.ume.nu> <1389304629.424.44.camel@belkin5> <52CF1D7C.4030700@gentoo.org> <20140109232116.398080f1@gentoo.org> <52CF22C6.6030907@gentoo.org> <20140109173046.65952ac8@caribou.gateway.pace.com> <20140109181748.6ce650fc@caribou.gateway.pace.com> In-Reply-To: <20140109181748.6ce650fc@caribou.gateway.pace.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: d2eda497-1b7b-4f64-8302-b26cb71409df X-Archives-Hash: 1ed648fdb45658ed05d72ef682c54116 -----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-----