* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 21:11 ` Ryan Hill
@ 2013-09-07 23:08 ` Rick "Zero_Chaos" Farina
2013-09-07 23:12 ` Rich Freeman
2013-09-09 0:06 ` Ryan Hill
2013-09-08 11:05 ` Martin Vaeth
` (2 subsequent siblings)
3 siblings, 2 replies; 45+ messages in thread
From: Rick "Zero_Chaos" Farina @ 2013-09-07 23:08 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/07/2013 05:11 PM, Ryan Hill wrote:
> On Sat, 7 Sep 2013 18:10:42 +0000 (UTC)
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>
>> Ryan Hill <dirtyepic@gentoo.org> wrote:
>>>
>>> * -fstack-protector{-all}
>>> No thank you. -fstack-protector has very limited coverage
>>
>> I'd say it covers most cases where bugs can be made,
>> practically without a severe impact on execution time or code size.
>
> The numbers I've seen show a maximum of 5% coverage for code that has a large
> number of functions containing char arrays on the stack. Most code doesn't fall
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are
> really old numbers though. The most recent I've seen is Chromium's coverage is
> <2%. There is an upper bound of 8% performance overhead using -fstack-protector
> according to the design spec. If you guys are okay with that then we can try
> enabling it for 4.8.1.
Personally I think this would be a great stepping stone. If we add
- -fstack-protector to 4.8.1 it will improve security (only a little I
know) and give us an idea of what issues we may have. After a short
enjoyment of fixing any issues which come up we could more to
- -fstack-protector-strong in 4.9.
Personally I'm using the hardened profile already and find the
performance penalties negligible for a desktop user, and someone trying
to run realtime on defaults is likely suicidal anyway.
Thanks,
Zero
>
>>> * -Wl,-z,relro
>>> Enabled by default since binutils 2.18
>>
>> This gives its real impact on secutiry only when combined with
>>
>> * -Wl,-z,now
>>
>> The latter is not enabled by default AFAIK.
>
> That's a bit misleading. Immediate binding does allow the GOT to be made
> readonly but relro does a lot more than that. In any case this is a firm no.
> The increase in loading times for apps that link lots of libraries is
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want full
> relro, enable it yourself or use hardened.
>
>> I would like to suggest also another flag
>>
>> * -Wl,-z,noexecstack
>>
>> This should be the default, but e.g. some broken gcc versions
>> forgot this default when using -flto.
>> I am using this flag since I realized this -flto bug and never
>> had any problems with it.
>
> Well, portage will already tell you if your package installed any binaries with
> executable stacks and I don't see many of those warnings that aren't binary
> packages so I think we're good.
>
>>
>>> * -Wl,--hash-style={both,gnu}
>>
>> I don't know what this has to do with security.
>
> I'm just responding to the list on the Ubuntu page.
>
>> However, isn't it time to use "gnu" now for all users? Except for
>> very strange binary-only code it should not cause any problems.
>> The majority of users would not realize a difference but profit
>> from smaller binaries.
>
> Sure, but the sysv hash is teeny and backward compatibility is always nice if
> it's next to free.
>
> Here are some more resources if anyone is interested:
>
> https://wiki.debian.org/Hardening
> https://bugs.archlinux.org/task/18864
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSK7IJAAoJEKXdFCfdEflKdIkP/3dQpOuzSlzMcXD68oD2L5HP
1ZrgAZzPkBKUOEvlH6WuCIC48k0GdeWCojz4kgo6LM8O3rsn3WRBO1iWbUjSxFja
P8W6bsLJw4t9Tuwk6GJvW0blM66lwQub2+MOynv8DRKloIoQ7yJZmlS1MurcNZFk
AQhl+3xoBpwkXIoR5zCJg0ipMuLV5PdqrtFp7VlPrs3yQfuFw/dxU2+sjo6Kau4a
WvPHzZWco328jVwPHh9F+nFD4F8jKXmBKwy3moOwFkh5a9XnJH3amG7sK37oNWVx
OkQ1pRPaBUyTvNOpA83kQFoa0I6ZWDLK/sCtxtNjadGBKHRwdMWBGN+iZWYH3CEv
uNJBxrJkMbubEpvRK/3nf+fvfa8ChNBbbZlOxyaZ50UCT7KtQ9S0VQWVjYuNYLQy
k9Yzc9jNcEilY5ux0RYqaAosZKso3ePkmbBfZLUs8E2F2C7NwJkhj5tv0AGAWt+n
kN+9MlL/rQhlVh6FtobZVs2DfVxfC87vA0MKJFOoqsOR1w5p2f+mKAUMqJi4jEHJ
ElyJdgIP3KegBIRVp1N9URofA8mIA1fh0Ef3JMx6020LVFXBuO5lihtrLCLR+t5h
PmHrmfbLS1SS/qsN/OavGaYjOhMExcJwNFnuguhNFIcQUdLUmTRzXf7uQ9b1zrbg
ZxLySFNAMubNMQf9Q9j/
=TPkK
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 23:08 ` Rick "Zero_Chaos" Farina
@ 2013-09-07 23:12 ` Rich Freeman
2013-09-08 14:12 ` Hinnerk van Bruinehsen
2013-09-09 0:06 ` Ryan Hill
1 sibling, 1 reply; 45+ messages in thread
From: Rich Freeman @ 2013-09-07 23:12 UTC (permalink / raw
To: gentoo-dev
On Sat, Sep 7, 2013 at 7:08 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Personally I'm using the hardened profile already and find the
> performance penalties negligible for a desktop user, and someone trying
> to run realtime on defaults is likely suicidal anyway.
I suspect what keeps people away from hardened isn't the performance,
but the risk of compatibility issues. Most operations these days
aren't CPU-bound, but getting something like RBAC to work right is
fairly involved...
Rich
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 23:12 ` Rich Freeman
@ 2013-09-08 14:12 ` Hinnerk van Bruinehsen
0 siblings, 0 replies; 45+ messages in thread
From: Hinnerk van Bruinehsen @ 2013-09-08 14:12 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On Sat, Sep 07, 2013 at 07:12:04PM -0400, Rich Freeman wrote:
> On Sat, Sep 7, 2013 at 7:08 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
> > Personally I'm using the hardened profile already and find the
> > performance penalties negligible for a desktop user, and someone trying
> > to run realtime on defaults is likely suicidal anyway.
>
> I suspect what keeps people away from hardened isn't the performance,
> but the risk of compatibility issues. Most operations these days
> aren't CPU-bound, but getting something like RBAC to work right is
> fairly involved...
>
> Rich
Hi,
from a longtime user perspective: I'm using hardened on desktops since about three or
four years now and I can't remember any issues that were caused by the
toolchain. Performance loss is imho negligible even on low powered systems like an
atom netbook or my Raspberry Pi (I'm not saying, that there is none, but it's
nothing dramatical).
RBAC, SELinux or a PaX enabled kernel is a completly other matter (in terms of
breakage and usability) but this thread was about toolchain not kernel, wasn't it?
WKR
Hinnerk
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 23:08 ` Rick "Zero_Chaos" Farina
2013-09-07 23:12 ` Rich Freeman
@ 2013-09-09 0:06 ` Ryan Hill
2013-09-09 12:11 ` Martin Vaeth
` (4 more replies)
1 sibling, 5 replies; 45+ messages in thread
From: Ryan Hill @ 2013-09-09 0:06 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
On Sat, 07 Sep 2013 19:08:57 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> Personally I think this would be a great stepping stone. If we add
> - -fstack-protector to 4.8.1 it will improve security (only a little I
> know) and give us an idea of what issues we may have. After a short
> enjoyment of fixing any issues which come up we could more to
> - -fstack-protector-strong in 4.9.
Okay it won't be available for 4.8.1. It's going to require a couple minor
glibc changes and a lot of testing. A bunch of packages stick workarounds
behind a hardened USE flag or do things like `filter-flags -fstack-protector`
which don't actually work (we have to patch the compiler, not just add it to
the default flags in the profiles or something). I need to check the
interactions with hardened's spec files. And I need to get 4.8.1 out the door
two weeks ago. Once we fix the fallout from the unmasking I'll get back to this.
I also want to make a comment on the implications of this change that people
may not have considered. Bugs caused by -fstack-protector can no longer be
just dismissed as unsupported, invalid, or assigned to the hardened team and
forgotten about. You will be expected to fix them, and `append-flags
-fno-stack-protector` is not an acceptable fix. You can't champion for more
secure defaults and then just disable them when they get in your way.
So does anyone have any objections to making -fstack-protector the default?
Now is the time to speak up.
(and for the record I've changed my mind and would like to see this go forward,
so please stop emailing me)
--
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 --]
^ permalink raw reply [flat|nested] 45+ messages in thread* [gentoo-dev] Re: Improve the security of the default profile
2013-09-09 0:06 ` Ryan Hill
@ 2013-09-09 12:11 ` Martin Vaeth
2013-09-09 12:21 ` Rich Freeman
` (3 subsequent siblings)
4 siblings, 0 replies; 45+ messages in thread
From: Martin Vaeth @ 2013-09-09 12:11 UTC (permalink / raw
To: gentoo-dev
Ryan Hill <dirtyepic@gentoo.org> wrote:
>
> You will be expected to fix them, and `append-flags
> -fno-stack-protector` is not an acceptable fix.
I guess there might be some projects with special
assembler code where this is the only possiblity.
For your information, I attach my list of packages
(of about 1400 installed ones) for which I had seen
a reason to exclude them from -fstack-protector
The reasons why they are in the list, I forgot long ago;
might be failure of some version with ARCH=x86 or
ARCH=amd64 or just carefulness like for grub:
app-emulation/wine
dev-libs/klibc
media-gfx/splashutils
sys-apps/texinfo
sys-apps/v86d
sys-boot/grub
sys-devel/llvm
In addition also:
sys-libs/glibc
sys-devel/gcc
(for the latter, I found an old note that
www-plugins/nspluginwrapper failed on amd64
if gcc itself was compiled with -fstack-protector;
I guessed some multilib issue but never examined).
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-09 0:06 ` Ryan Hill
2013-09-09 12:11 ` Martin Vaeth
@ 2013-09-09 12:21 ` Rich Freeman
2013-09-10 3:00 ` Ryan Hill
2013-09-10 17:50 ` Jeroen Roovers
` (2 subsequent siblings)
4 siblings, 1 reply; 45+ messages in thread
From: Rich Freeman @ 2013-09-09 12:21 UTC (permalink / raw
To: gentoo-dev
On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> You will be expected to fix them, and `append-flags
> -fno-stack-protector` is not an acceptable fix. You can't champion for more
> secure defaults and then just disable them when they get in your way.
Why not? Surely a system where 99.9% of the packages installed are
hardened is more secure than a system where 0% of the packages
installed are hardened.
> So does anyone have any objections to making -fstack-protector the default?
> Now is the time to speak up.
So, in this world of all-or-nothing we want people who realize that
100% protection might not be possible to raise an objection so that we
end up with 0% protection instead?
Why not just do the sensible thing (IMHO) and make it a default, and
then if it doesn't work for an individual package deal with it on an
individual basis? We already encourage maintainers to try to get
custom CFLAGS to work when practical, but when not practical we filter
them. I don't see stack protection as any different. If there is a
fix, then fix it, and if not, then disable it. I don't see a lack of
stack-protection as a reason to keep something out of the tree.
Rich
^ permalink raw reply [flat|nested] 45+ messages in thread* [gentoo-dev] Re: Improve the security of the default profile
2013-09-09 12:21 ` Rich Freeman
@ 2013-09-10 3:00 ` Ryan Hill
2013-09-10 3:46 ` Peter Stuge
2013-09-11 22:04 ` Magnus Granberg
0 siblings, 2 replies; 45+ messages in thread
From: Ryan Hill @ 2013-09-10 3:00 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]
On Mon, 9 Sep 2013 08:21:35 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> > So does anyone have any objections to making -fstack-protector the default?
> > Now is the time to speak up.
>
> So, in this world of all-or-nothing we want people who realize that
> 100% protection might not be possible to raise an objection so that we
> end up with 0% protection instead?
No, all I've heard so far is support and wanted to give anyone with an opposing
viewpoint a chance to speak up. I support it, but if there are any problems we
might run into it's best we know about them beforehand, no? I wasn't looking
for a reason to veto it.
> Why not just do the sensible thing (IMHO) and make it a default, and
> then if it doesn't work for an individual package deal with it on an
> individual basis? We already encourage maintainers to try to get
> custom CFLAGS to work when practical, but when not practical we filter
> them. I don't see stack protection as any different. If there is a
> fix, then fix it, and if not, then disable it. I don't see a lack of
> stack-protection as a reason to keep something out of the tree.
Rich, that's exactly what I'm saying.
We have to make an effort to fix things properly, like we do with any supported
feature. That's something I see as one of the key strengths of this group we
have. Obviously there are cases where a fix isn't possible (glibc and gcc
itself are prime examples) and we need to disable it. That's fine. But we
need to discourage people sweeping problems under the rug because they're
inconvenient, especially when those problems may indicate security issues.
I'm just trying to set proper expectations - that this change may break
people's packages, and they may have to do some work to find out why and how to
fix it. I don't like creating more work for people, so I want to be sure there
is consensus on this first. So far it sounds like there is.
--
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 --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-10 3:00 ` Ryan Hill
@ 2013-09-10 3:46 ` Peter Stuge
2013-09-11 22:04 ` Magnus Granberg
1 sibling, 0 replies; 45+ messages in thread
From: Peter Stuge @ 2013-09-10 3:46 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
Ryan Hill wrote:
> I don't like creating more work for people, so I want to be sure
> there is consensus on this first. So far it sounds like there is.
I think there will come enough objections, but only down the road,
and only from people who don't want to care about quality.
Don't let that stop the improvements from happening.
Thanks
//Peter
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-10 3:00 ` Ryan Hill
2013-09-10 3:46 ` Peter Stuge
@ 2013-09-11 22:04 ` Magnus Granberg
1 sibling, 0 replies; 45+ messages in thread
From: Magnus Granberg @ 2013-09-11 22:04 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
måndag 09 september 2013 21.00.12 skrev Ryan Hill:
> On Mon, 9 Sep 2013 08:21:35 -0400
>
> Rich Freeman <rich0@gentoo.org> wrote:
> > On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> > > So does anyone have any objections to making -fstack-protector the
> > > default?
> > > Now is the time to speak up.
> >
> > So, in this world of all-or-nothing we want people who realize that
> > 100% protection might not be possible to raise an objection so that we
> > end up with 0% protection instead?
>
> No, all I've heard so far is support and wanted to give anyone with an
> opposing viewpoint a chance to speak up. I support it, but if there are
> any problems we might run into it's best we know about them beforehand, no?
> I wasn't looking for a reason to veto it.
>
> > Why not just do the sensible thing (IMHO) and make it a default, and
> > then if it doesn't work for an individual package deal with it on an
> > individual basis? We already encourage maintainers to try to get
> > custom CFLAGS to work when practical, but when not practical we filter
> > them. I don't see stack protection as any different. If there is a
> > fix, then fix it, and if not, then disable it. I don't see a lack of
> > stack-protection as a reason to keep something out of the tree.
>
> Rich, that's exactly what I'm saying.
>
> We have to make an effort to fix things properly, like we do with any
> supported feature. That's something I see as one of the key strengths of
> this group we have. Obviously there are cases where a fix isn't possible
> (glibc and gcc itself are prime examples) and we need to disable it.
> That's fine. But we need to discourage people sweeping problems under the
> rug because they're inconvenient, especially when those problems may
> indicate security issues.
>
> I'm just trying to set proper expectations - that this change may break
> people's packages, and they may have to do some work to find out why and how
> to fix it. I don't like creating more work for people, so I want to be
> sure there is consensus on this first. So far it sounds like there is.
I did build most of the packages (~14000 packages) in tree when we move from
gcc 3.X to 4.X with stack protection and some packages didn't work but we fix
it or added work work arounds to them. So in short most of the package work
is allready done.
/Magnus
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-09 0:06 ` Ryan Hill
2013-09-09 12:11 ` Martin Vaeth
2013-09-09 12:21 ` Rich Freeman
@ 2013-09-10 17:50 ` Jeroen Roovers
2013-09-10 22:41 ` Richard Yao
[not found] ` <522FA01E.4070602 @gentoo.org>
4 siblings, 0 replies; 45+ messages in thread
From: Jeroen Roovers @ 2013-09-10 17:50 UTC (permalink / raw
To: gentoo-dev
On Sun, 8 Sep 2013 18:06:56 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> So does anyone have any objections to making -fstack-protector the
> default? Now is the time to speak up.
On PARISC you get plenty of warning of how well it's going to work out:
(cc1|gcc|foo): warning: -fstack-protector not supported for this target
[enabled by default]
jer
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-09 0:06 ` Ryan Hill
` (2 preceding siblings ...)
2013-09-10 17:50 ` Jeroen Roovers
@ 2013-09-10 22:41 ` Richard Yao
2013-09-11 1:17 ` Rich Freeman
2013-09-11 6:07 ` Ryan Hill
[not found] ` <522FA01E.4070602 @gentoo.org>
4 siblings, 2 replies; 45+ messages in thread
From: Richard Yao @ 2013-09-10 22:41 UTC (permalink / raw
To: gentoo-dev; +Cc: Ryan Hill, Agostino Sarubbo
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]
On 09/08/2013 08:06 PM, Ryan Hill wrote:
> On Sat, 07 Sep 2013 19:08:57 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
>
>> Personally I think this would be a great stepping stone. If we add
>> - -fstack-protector to 4.8.1 it will improve security (only a little I
>> know) and give us an idea of what issues we may have. After a short
>> enjoyment of fixing any issues which come up we could more to
>> - -fstack-protector-strong in 4.9.
>
> Okay it won't be available for 4.8.1. It's going to require a couple minor
> glibc changes and a lot of testing. A bunch of packages stick workarounds
> behind a hardened USE flag or do things like `filter-flags -fstack-protector`
> which don't actually work (we have to patch the compiler, not just add it to
> the default flags in the profiles or something). I need to check the
> interactions with hardened's spec files. And I need to get 4.8.1 out the door
> two weeks ago. Once we fix the fallout from the unmasking I'll get back to this.
>
> I also want to make a comment on the implications of this change that people
> may not have considered. Bugs caused by -fstack-protector can no longer be
> just dismissed as unsupported, invalid, or assigned to the hardened team and
> forgotten about. You will be expected to fix them, and `append-flags
> -fno-stack-protector` is not an acceptable fix. You can't champion for more
> secure defaults and then just disable them when they get in your way.
>
> So does anyone have any objections to making -fstack-protector the default?
> Now is the time to speak up.
>
>
>
> (and for the record I've changed my mind and would like to see this go forward,
> so please stop emailing me)
>
>
A few thoughts:
1. The kernel expects -fno-stack-protector to be the default. What will
the effect be on kernel configuration once -fstack-protector is the default?
2. We should make sure that -fno-stack-protector is a supported CFLAG.
This will make it easier to handle complaints from the vocal minority of
our user base that want every last percentage point of performance.
3. I would like to point out that we are talking about deviating from
upstream behavior and everyone is okay with it. Anyone who thinks we
should stick to upstream when it is not good for us should speak now or
risk being asked "where were you when..." whenever they try to use
upstream as an excuse to hold back progress. ;)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-10 22:41 ` Richard Yao
@ 2013-09-11 1:17 ` Rich Freeman
2013-09-12 15:03 ` Richard Yao
2013-09-11 6:07 ` Ryan Hill
1 sibling, 1 reply; 45+ messages in thread
From: Rich Freeman @ 2013-09-11 1:17 UTC (permalink / raw
To: gentoo-dev; +Cc: Ryan Hill, Agostino Sarubbo
On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@gentoo.org> wrote:
> 1. The kernel expects -fno-stack-protector to be the default. What will
> the effect be on kernel configuration once -fstack-protector is the default?
Nothing, since the kernel build system doesn't source make.conf. If
somebody creates an ebuild that actually installs a kernel then it
might be an issue, though it could be filtered if it is a problem.
>
> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
> This will make it easier to handle complaints from the vocal minority of
> our user base that want every last percentage point of performance.
No reason that it would be any less supported than -fstack-protector
already is.
>
> 3. I would like to point out that we are talking about deviating from
> upstream behavior and everyone is okay with it. Anyone who thinks we
> should stick to upstream when it is not good for us should speak now or
> risk being asked "where were you when..." whenever they try to use
> upstream as an excuse to hold back progress. ;)
I don't really see this as an issue - in general maintainers are
expected to accommodate reasonable CFLAGS. This doesn't mean that
arbitrary CFLAGS are "supported" so much as bugs should be taken
seriously if they're really bugs. If -fstack-protector causes serious
problems and this is inherent to the nature of the package/etc then
just filter it. If it causes problems because upstream isn't doing
things right, then this is no different than how things were 10 years
ago when we were stomping out amd64 issues left and right (not working
on amd64 wasn't a reason to mask a package for x86, but we didn't
accept "upstream doesn't care about amd64" as an excuse).
Staying close to upstream is a good philosophy in general. I don't
think that means that we can't have reasonable CFLAGS. Otherwise we
wouldn't set CFLAGS at all and would just use whatever defaults the
upstream build system applies. We're a distro - doing integration
work is a value-add, not a sin. If we aren't doing integration, then
users might as well just do Linux-from-scratch.
Rich
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-11 1:17 ` Rich Freeman
@ 2013-09-12 15:03 ` Richard Yao
2013-09-12 15:12 ` Richard Yao
0 siblings, 1 reply; 45+ messages in thread
From: Richard Yao @ 2013-09-12 15:03 UTC (permalink / raw
To: gentoo-dev; +Cc: Rich Freeman, Ryan Hill, Agostino Sarubbo
[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]
On 09/10/2013 09:17 PM, Rich Freeman wrote:
> On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@gentoo.org> wrote:
>> 1. The kernel expects -fno-stack-protector to be the default. What will
>> the effect be on kernel configuration once -fstack-protector is the default?
>
> Nothing, since the kernel build system doesn't source make.conf. If
> somebody creates an ebuild that actually installs a kernel then it
> might be an issue, though it could be filtered if it is a problem.
My understanding is that this change would be made to GCC's spec files,
which affects everything that uses GCC.
>>
>> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
>> This will make it easier to handle complaints from the vocal minority of
>> our user base that want every last percentage point of performance.
>
> No reason that it would be any less supported than -fstack-protector
> already is.
Just making certain.
>>
>> 3. I would like to point out that we are talking about deviating from
>> upstream behavior and everyone is okay with it. Anyone who thinks we
>> should stick to upstream when it is not good for us should speak now or
>> risk being asked "where were you when..." whenever they try to use
>> upstream as an excuse to hold back progress. ;)
>
> I don't really see this as an issue - in general maintainers are
> expected to accommodate reasonable CFLAGS. This doesn't mean that
> arbitrary CFLAGS are "supported" so much as bugs should be taken
> seriously if they're really bugs. If -fstack-protector causes serious
> problems and this is inherent to the nature of the package/etc then
> just filter it. If it causes problems because upstream isn't doing
> things right, then this is no different than how things were 10 years
> ago when we were stomping out amd64 issues left and right (not working
> on amd64 wasn't a reason to mask a package for x86, but we didn't
> accept "upstream doesn't care about amd64" as an excuse).
>
> Staying close to upstream is a good philosophy in general. I don't
> think that means that we can't have reasonable CFLAGS. Otherwise we
> wouldn't set CFLAGS at all and would just use whatever defaults the
> upstream build system applies. We're a distro - doing integration
> work is a value-add, not a sin. If we aren't doing integration, then
> users might as well just do Linux-from-scratch.
>
> Rich
>
Past events have led me to think that we are sometimes too dependent on
upstream for guidance. I have certainly deviated from upstream whenever
it made sense and the results have been fairly positive. I am not saying
that acting for the best interests of Gentoo is mutually exclusive with
collaboration with upstream, but I am saying that the two sometimes
conflict. This being one of them. I am taking this opportunity to point
out that what is best for Gentoo should come first and that it is okay
to make decisions on our own.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-12 15:03 ` Richard Yao
@ 2013-09-12 15:12 ` Richard Yao
0 siblings, 0 replies; 45+ messages in thread
From: Richard Yao @ 2013-09-12 15:12 UTC (permalink / raw
To: gentoo-dev; +Cc: Rich Freeman, Ryan Hill, Agostino Sarubbo
[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]
On 09/12/2013 11:03 AM, Richard Yao wrote:
> On 09/10/2013 09:17 PM, Rich Freeman wrote:
>> On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@gentoo.org> wrote:
>>> 1. The kernel expects -fno-stack-protector to be the default. What will
>>> the effect be on kernel configuration once -fstack-protector is the default?
>>
>> Nothing, since the kernel build system doesn't source make.conf. If
>> somebody creates an ebuild that actually installs a kernel then it
>> might be an issue, though it could be filtered if it is a problem.
>
> My understanding is that this change would be made to GCC's spec files,
> which affects everything that uses GCC.
>
>>>
>>> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
>>> This will make it easier to handle complaints from the vocal minority of
>>> our user base that want every last percentage point of performance.
>>
>> No reason that it would be any less supported than -fstack-protector
>> already is.
>
> Just making certain.
>
>>>
>>> 3. I would like to point out that we are talking about deviating from
>>> upstream behavior and everyone is okay with it. Anyone who thinks we
>>> should stick to upstream when it is not good for us should speak now or
>>> risk being asked "where were you when..." whenever they try to use
>>> upstream as an excuse to hold back progress. ;)
>>
>> I don't really see this as an issue - in general maintainers are
>> expected to accommodate reasonable CFLAGS. This doesn't mean that
>> arbitrary CFLAGS are "supported" so much as bugs should be taken
>> seriously if they're really bugs. If -fstack-protector causes serious
>> problems and this is inherent to the nature of the package/etc then
>> just filter it. If it causes problems because upstream isn't doing
>> things right, then this is no different than how things were 10 years
>> ago when we were stomping out amd64 issues left and right (not working
>> on amd64 wasn't a reason to mask a package for x86, but we didn't
>> accept "upstream doesn't care about amd64" as an excuse).
>>
>> Staying close to upstream is a good philosophy in general. I don't
>> think that means that we can't have reasonable CFLAGS. Otherwise we
>> wouldn't set CFLAGS at all and would just use whatever defaults the
>> upstream build system applies. We're a distro - doing integration
>> work is a value-add, not a sin. If we aren't doing integration, then
>> users might as well just do Linux-from-scratch.
>>
>> Rich
>>
>
> Past events have led me to think that we are sometimes too dependent on
> upstream for guidance. I have certainly deviated from upstream whenever
> it made sense and the results have been fairly positive. I am not saying
> that acting for the best interests of Gentoo is mutually exclusive with
> collaboration with upstream, but I am saying that the two sometimes
> conflict. This being one of them. I am taking this opportunity to point
> out that what is best for Gentoo should come first and that it is okay
> to make decisions on our own.
>
I just checked the kernel's makefiles. It does pass -fno-stack-protector
when the option is disabled. Therefore a GCC spec file change will not
have cause GCC to generate kernels that differ from their .config files.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [gentoo-dev] Re: Improve the security of the default profile
2013-09-10 22:41 ` Richard Yao
2013-09-11 1:17 ` Rich Freeman
@ 2013-09-11 6:07 ` Ryan Hill
2013-09-11 18:23 ` Magnus Granberg
2013-09-12 15:07 ` Richard Yao
1 sibling, 2 replies; 45+ messages in thread
From: Ryan Hill @ 2013-09-11 6:07 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
On Tue, 10 Sep 2013 18:41:34 -0400
Richard Yao <ryao@gentoo.org> wrote:
> A few thoughts:
>
> 1. The kernel expects -fno-stack-protector to be the default. What will
> the effect be on kernel configuration once -fstack-protector is the default?
The kernel has supported building with -fstack-protector since 2.6.19, (at least
on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if it's
disabled then -fno-stack-protector is explicitly added to the command line.
> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
> This will make it easier to handle complaints from the vocal minority of
> our user base that want every last percentage point of performance.
If by supported you mean that they won't be removed by things like strip-flags,
then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and
-fno-stack-protector-all are all on the whitelist.
> 3. I would like to point out that we are talking about deviating from
> upstream behavior and everyone is okay with it. Anyone who thinks we
> should stick to upstream when it is not good for us should speak now or
> risk being asked "where were you when..." whenever they try to use
> upstream as an excuse to hold back progress. ;)
In this case it seems every other distro is already doing this, so we're in
good company.
--
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 --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-11 6:07 ` Ryan Hill
@ 2013-09-11 18:23 ` Magnus Granberg
2013-09-12 15:07 ` Richard Yao
1 sibling, 0 replies; 45+ messages in thread
From: Magnus Granberg @ 2013-09-11 18:23 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
onsdag 11 september 2013 00.07.29 skrev Ryan Hill:
> On Tue, 10 Sep 2013 18:41:34 -0400
>
> Richard Yao <ryao@gentoo.org> wrote:
> > A few thoughts:
> >
> > 1. The kernel expects -fno-stack-protector to be the default. What will
> > the effect be on kernel configuration once -fstack-protector is the
> > default?
> The kernel has supported building with -fstack-protector since 2.6.19, (at
> least on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if
> it's disabled then -fno-stack-protector is explicitly added to the command
> line.
On Hardened we disable -fstack-protector* when building kernel and it is done
with some gcc spec rules that we patch gcc with and it have been working long
before gcc 4.X versions. It can be turned on with the kernel config option
CONFIG_CC_STACKPROTECTOR.
/Magnus
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-11 6:07 ` Ryan Hill
2013-09-11 18:23 ` Magnus Granberg
@ 2013-09-12 15:07 ` Richard Yao
1 sibling, 0 replies; 45+ messages in thread
From: Richard Yao @ 2013-09-12 15:07 UTC (permalink / raw
To: gentoo-dev; +Cc: Ryan Hill
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On 09/11/2013 02:07 AM, Ryan Hill wrote:
> On Tue, 10 Sep 2013 18:41:34 -0400
> Richard Yao <ryao@gentoo.org> wrote:
>
>> A few thoughts:
>>
>> 1. The kernel expects -fno-stack-protector to be the default. What will
>> the effect be on kernel configuration once -fstack-protector is the default?
>
> The kernel has supported building with -fstack-protector since 2.6.19, (at least
> on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if it's
> disabled then -fno-stack-protector is explicitly added to the command line.
That is good news. I admit that I was being lazy in not looking this up
myself, but things probably are more efficient when the people already
looking into this are the ones who check these loose ends.
>> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
>> This will make it easier to handle complaints from the vocal minority of
>> our user base that want every last percentage point of performance.
>
> If by supported you mean that they won't be removed by things like strip-flags,
> then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and
> -fno-stack-protector-all are all on the whitelist.
That is good.
>> 3. I would like to point out that we are talking about deviating from
>> upstream behavior and everyone is okay with it. Anyone who thinks we
>> should stick to upstream when it is not good for us should speak now or
>> risk being asked "where were you when..." whenever they try to use
>> upstream as an excuse to hold back progress. ;)
>
> In this case it seems every other distro is already doing this, so we're in
> good company.
Agreed. I just wanted to say something as insurance for the future. ;)
Anyway, I will be happy to see it integrated into the tree once all of
the hacks around it have been corrected.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <522FA01E.4070602 @gentoo.org>]
* [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 21:11 ` Ryan Hill
2013-09-07 23:08 ` Rick "Zero_Chaos" Farina
@ 2013-09-08 11:05 ` Martin Vaeth
2013-09-09 3:24 ` Ryan Hill
2013-09-08 11:24 ` Martin Vaeth
2013-09-12 15:23 ` Anthony G. Basile
3 siblings, 1 reply; 45+ messages in thread
From: Martin Vaeth @ 2013-09-08 11:05 UTC (permalink / raw
To: gentoo-dev
Ryan Hill <dirtyepic@gentoo.org> wrote:
>
>> > * -Wl,-z,relro
>> > Enabled by default since binutils 2.18
>>
>> This gives its real impact on secutiry only when combined with
>>
>> * -Wl,-z,now
>>
>> The latter is not enabled by default AFAIK.
>
> That's a bit misleading. Immediate binding does allow the GOT to be made
> readonly but relro does a lot more than that.
It is somewhat pointless if not everything is readonly:
In analogy, "relro" without "now" is a bit like making all your files
readonly but leaving write-permissions on the directories.
It only helps against too poorly designed exploits of corresponding
bugs.
> In any case this is a firm no.
> The increase in loading times for apps that link lots of libraries is
> significant (if it wasn't, we wouldn't need lazy loading :p).
You get the same delay for lazy linking, only not necessarily
everything immediately when the application starts up.
And even then it is only faster (at startup) if only very few symbols
are needed near the beginning.
Quite the opposite, total time of loading huge projects like
kde or libreoffice can even be faster with "now", since you do
not need administration overhead for keeping track of resolving.
I did not realize a measurable difference for kde and libreoffice
even on my slow machines - random things like location on harddisk
apparently had a much bigger impact on startup.
Please really try before you fix your opinion.
>> * -Wl,-z,noexecstack
>
> Well, portage will already tell you if your package installed any
> binaries with executable stacks
For some it did warn - otherwise I would not have found the bug.
But for some it did not. However, I cannot recall which packages
these were, and I did not examine why.
Anyway, since this probably only concerns certain gcc versions
with -flto, I guess that we need not discuss much about this flag.
>> However, isn't it time to use "gnu" now for all users? [...]
>
> Sure, but the sysv hash is teeny and backward compatibility is
> always nice if it's next to free.
But it is not completely free, and the majority of users
will never have any need for it - in factõ I do not know
any use-case, but of course I do not know all ancient software
sitting around somewhere.
Those few who need it can add the option without difficulties.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [gentoo-dev] Re: Improve the security of the default profile
2013-09-08 11:05 ` Martin Vaeth
@ 2013-09-09 3:24 ` Ryan Hill
0 siblings, 0 replies; 45+ messages in thread
From: Ryan Hill @ 2013-09-09 3:24 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
On Sun, 8 Sep 2013 11:05:16 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > In any case this is a firm no.
> > The increase in loading times for apps that link lots of libraries is
> > significant (if it wasn't, we wouldn't need lazy loading :p).
> You get the same delay for lazy linking, only not necessarily
> everything immediately when the application starts up.
> And even then it is only faster (at startup) if only very few symbols
> are needed near the beginning.
>
> Quite the opposite, total time of loading huge projects like
> kde or libreoffice can even be faster with "now", since you do
> not need administration overhead for keeping track of resolving.
> I did not realize a measurable difference for kde and libreoffice
> even on my slow machines - random things like location on harddisk
> apparently had a much bigger impact on startup.
> Please really try before you fix your opinion.
I'm basing my opinion on the experiences reported by other distros, by
openwall, and by our own hardened team. In any case my opinion doesn't really
matter because in the end since I'm not the one who gets to make that
decision. I misrepresented that and I apologize. I would still be against
making this change.
> >> However, isn't it time to use "gnu" now for all users? [...]
> >
> > Sure, but the sysv hash is teeny and backward compatibility is
> > always nice if it's next to free.
>
> But it is not completely free, and the majority of users
> will never have any need for it - in factõ I do not know
> any use-case, but of course I do not know all ancient software
> sitting around somewhere.
> Those few who need it can add the option without difficulties.
FWIW I agree but I am not the binutils maintainer.
--
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 --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 21:11 ` Ryan Hill
2013-09-07 23:08 ` Rick "Zero_Chaos" Farina
2013-09-08 11:05 ` Martin Vaeth
@ 2013-09-08 11:24 ` Martin Vaeth
2013-09-12 15:23 ` Anthony G. Basile
3 siblings, 0 replies; 45+ messages in thread
From: Martin Vaeth @ 2013-09-08 11:24 UTC (permalink / raw
To: gentoo-dev
Ryan Hill <dirtyepic@gentoo.org> wrote:
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>> >
>> > * -fstack-protector{-all}
>> > No thank you. -fstack-protector has very limited coverage
>>
>> I'd say it covers most cases where bugs can be made, [...]
>
> The numbers I've seen show a maximum of 5% coverage for code that has a
> large number of functions containing char arrays on the stack.
If you have no local array on the stack, it is rather hard to write
accidentally(!) code in the function which corrupts the stack.
(It still is possible e.g. through bad casting, but it is rather
unlikely that this happens by accident).
So coverage of these functions covers most cases of accidental bugs.
Of course, as Ciaranm already mentioned, there is no compiler flag
which transforms unsafe code into safe one, but if even just one or
two security bugs can be avoid this way, it was worth to add
this flag IMHO.
> Most code doesn't fall into that category.
Isn't this good news? It means most code will not get *any*
penalty with -fstack-protector.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [gentoo-dev] Re: Improve the security of the default profile
2013-09-07 21:11 ` Ryan Hill
` (2 preceding siblings ...)
2013-09-08 11:24 ` Martin Vaeth
@ 2013-09-12 15:23 ` Anthony G. Basile
2013-09-13 6:08 ` Ryan Hill
3 siblings, 1 reply; 45+ messages in thread
From: Anthony G. Basile @ 2013-09-12 15:23 UTC (permalink / raw
To: gentoo-dev
On 09/07/2013 05:11 PM, Ryan Hill wrote:
> On Sat, 7 Sep 2013 18:10:42 +0000 (UTC)
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>
>> Ryan Hill <dirtyepic@gentoo.org> wrote:
>>> * -fstack-protector{-all}
>>> No thank you. -fstack-protector has very limited coverage
>> I'd say it covers most cases where bugs can be made,
>> practically without a severe impact on execution time or code size.
> The numbers I've seen show a maximum of 5% coverage for code that has a large
> number of functions containing char arrays on the stack. Most code doesn't fall
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are
> really old numbers though. The most recent I've seen is Chromium's coverage is
> <2%. There is an upper bound of 8% performance overhead using -fstack-protector
> according to the design spec. If you guys are okay with that then we can try
> enabling it for 4.8.1.
>
>>> * -Wl,-z,relro
>>> Enabled by default since binutils 2.18
>> This gives its real impact on secutiry only when combined with
>>
>> * -Wl,-z,now
>>
>> The latter is not enabled by default AFAIK.
> That's a bit misleading. Immediate binding does allow the GOT to be made
> readonly but relro does a lot more than that. In any case this is a firm no.
> The increase in loading times for apps that link lots of libraries is
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want full
> relro, enable it yourself or use hardened.
>
>> I would like to suggest also another flag
>>
>> * -Wl,-z,noexecstack
>>
>> This should be the default, but e.g. some broken gcc versions
>> forgot this default when using -flto.
>> I am using this flag since I realized this -flto bug and never
>> had any problems with it.
> Well, portage will already tell you if your package installed any binaries with
> executable stacks and I don't see many of those warnings that aren't binary
> packages so I think we're good.
>
>>> * -Wl,--hash-style={both,gnu}
>> I don't know what this has to do with security.
> I'm just responding to the list on the Ubuntu page.
>
>> However, isn't it time to use "gnu" now for all users? Except for
>> very strange binary-only code it should not cause any problems.
>> The majority of users would not realize a difference but profit
>> from smaller binaries.
> Sure, but the sysv hash is teeny and backward compatibility is always nice if
> it's next to free.
>
> Here are some more resources if anyone is interested:
>
> https://wiki.debian.org/Hardening
> https://bugs.archlinux.org/task/18864
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
>
The hardened team has talked about this in IRC and our general feeling
is that adding *just* ssp to vanilla gcc specs is okay. While there are
some performance hits, it is generally safe and should cause little
problems to our users. The other hardened features, however, have more
of an impact and probably don't belong in vanilla as already discussed.
--
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
^ permalink raw reply [flat|nested] 45+ messages in thread