public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
Date: Thu, 09 Jan 2014 18:13:33 -0500	[thread overview]
Message-ID: <52CF2D1D.10709@gentoo.org> (raw)
In-Reply-To: <52CF2A4D.5000703@gentoo.org>

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


  reply	other threads:[~2014-01-09 23:13 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
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 [this message]
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=52CF2D1D.10709@gentoo.org \
    --to=zerochaos@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