public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
Date: Thu, 9 Jan 2014 18:17:48 -0600	[thread overview]
Message-ID: <20140109181748.6ce650fc@caribou.gateway.pace.com> (raw)
In-Reply-To: 20140109173046.65952ac8@caribou.gateway.pace.com

[-- 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 --]

  reply	other threads:[~2014-01-10  0:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 20:58 [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes Magnus Granberg
2014-01-09 21:11 ` Rick "Zero_Chaos" Farina
2014-01-09 22:19   ` William Hubbs
2014-01-09 23:26   ` [gentoo-dev] " Ryan Hill
2014-01-09 23:30     ` Andreas K. Huettel
2014-01-09 23:41       ` William Hubbs
2014-01-10  0:12         ` Ryan Hill
2014-01-10  6:35           ` Rick "Zero_Chaos" Farina
2014-01-10 15:50             ` Ryan Hill
2014-01-10 18:37               ` Rick "Zero_Chaos" Farina
2014-01-10 20:08               ` Anthony G. Basile
2014-01-10 21:56                 ` Ryan Hill
2014-01-09 21:57 ` [gentoo-dev] " Pacho Ramos
2014-01-09 22:06   ` Anthony G. Basile
2014-01-09 22:16     ` Pacho Ramos
2014-01-09 22:21     ` Michał Górny
2014-01-09 22:29       ` Rick "Zero_Chaos" Farina
2014-01-09 23:03         ` Anthony G. Basile
2014-01-09 23:09         ` Anthony G. Basile
2014-01-09 23:19           ` Rick "Zero_Chaos" Farina
2014-01-09 23:30         ` [gentoo-dev] " Ryan Hill
2014-01-10  0:17           ` Ryan Hill [this message]
2014-01-10  6:39             ` Rick "Zero_Chaos" Farina
2014-01-09 23:59         ` [gentoo-dev] " Rich Freeman
2014-01-10  4:50           ` Michał Górny
2014-01-09 23:01       ` Anthony G. Basile
2014-01-09 23:13         ` Rick "Zero_Chaos" Farina
2014-01-09 23:28           ` Anthony G. Basile
2014-01-09 22:07   ` Magnus Granberg
2014-01-09 23:56 ` [gentoo-dev] " Ryan Hill
2014-01-10 15:45   ` Magnus Granberg
2014-01-10  5:18 ` Ryan Hill
2014-01-10 15:24   ` Magnus Granberg
2014-01-10 16:30     ` Ryan Hill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140109181748.6ce650fc@caribou.gateway.pace.com \
    --to=dirtyepic@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox