From: "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
Date: Fri, 10 Jan 2014 01:39:58 -0500 [thread overview]
Message-ID: <52CF95BE.8060904@gentoo.org> (raw)
In-Reply-To: <20140109181748.6ce650fc@caribou.gateway.pace.com>
-----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-----
next prev parent reply other threads:[~2014-01-10 6:39 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 [this message]
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=52CF95BE.8060904@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