From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3FF5C138247 for ; Thu, 9 Jan 2014 23:03:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 22EB5E0C5D; Thu, 9 Jan 2014 23:03: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 3E275E0C2F for ; Thu, 9 Jan 2014 23:03:41 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 4BBA333EEB4 for ; Thu, 9 Jan 2014 23:03:40 +0000 (UTC) Message-ID: <52CF2ACF.1090305@gentoo.org> Date: Thu, 09 Jan 2014 18:03:43 -0500 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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] [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> In-Reply-To: <52CF22C6.6030907@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 9933d8bd-a953-4059-bb0d-edfdcf92a877 X-Archives-Hash: 61ba17c1be06856c139d0434473dee05 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" 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