owl-dev - %optflags for new gcc

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120204155054.GA8732@albatros>
Date: Sat, 4 Feb 2012 19:50:54 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: %optflags for new gcc

Hi,

Solar, all -

Refreshing the subject, I'd want to discuss again the need of default
gcc options changing.

First, the options (please, comment them in separate emails unless
the comment is trivial/groupped to ease email search in future):

1) Use -Os instead of -O2.

Solar said: "I am not going to do this now.  It is not obvious to me
whether "-Os -fomit-frame-pointer" or -O2 (with -fomit-frame-pointer
implied) is more appropriate for a distro."

2) -mpreferred-stack-boundary* 

I am a bit lost in the discussions (actually, more Solar's tests :)).
Where are we now?  Do we still need these changes?

3) -Wl,-z,relro

With this option in %optflags there are many binaries built without
relro as their spec files don't use %optflags.  I suggest to patch gcc
to use relro by default, as Ubuntu and ALT do.  My buildworld testing
showed no visible issues, all binaries in {/,/usr/}{s,}bin were
relro'ed.

4) -fstack-protector --param=ssp-buffer-size=2

5) PIE/pie

6) -D_FORTIFY_SOURCE=2

For (6) and (4) we need glibc update first.  AFAIU, (5) needs modern
glibc too.

As Solar said, we're able to use -fstack-protector somehow
without glibc, but not to do double work, just enable it with modern
glibc.

7) -fexceptions.

I haven't spotted any negative opinions on this.  To be more binary
compatible with Fedora/RHEL we should enable it too.  It could slightly
slowdown C code using C libraries, though.  I cannot find anything
related to the slowdown, so it should be negligible.

8) -Wl,-z,now

I agree with Pavel here that we should use secure defaults and disable
-z,now only for those binaries which do suffer from slow startups like
php or perl.  Are there other widespread use cases where startup
slowdown is significant?

Another question: how should we handle cases where %optflags* are not
passed to gcc (spec file mistake)?  I see 3 solutions:

1) Ignore the missing %optflags* for now, but add it to the spec file as
soon as we upgrade the software in Owl.

2) Fix all spec files now.

3) Enable all security options (listed above) as gcc (binutils?)
defaults.  Do the same as in (1) while upgrading our packages.

I don't like (2) and prefer (3).  I agree with Pavel that we should
prefer security in general and tune only the software which really needs
these 1-10% speedups.

So, my plan for now is:

1) enable -z,relro and -z,now as gcc defaults.

2) enable -fexceptions in rpmmacros.

3) upgrade glibc (this is a separate subject).

4) enable D_FORTIFY_SOURCE, PIE, SSP as gcc defaults.

5) look what specs should have these security options disabled.
(Probably do it during all 1-4 phases.)

Any comments, suggestions, opinions are welcome.

Thanks,

-- 
Vasiliy

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.