[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Feb 2012 13:25:19 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: %optflags for new gcc
On Sat, Feb 04, 2012 at 07:50:54PM +0400, Vasiliy Kulikov wrote:
> 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."
That comment of mine is outdated. I've since done more benchmarks and
concluded that we should not use -Os as default. I think I posted about
that in here.
BTW, regarding the new -fomit-frame-pointer default I opened this gcc
bug because the documentation is not clear:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51019
(although the actual behavior is reasonable).
> 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?
I'll comment on this separately.
> 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.
Yes, we decided to do that.
> 4) -fstack-protector --param=ssp-buffer-size=2
Yes, this should also be gcc default.
> 5) PIE/pie
Not yet.
> 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.
I am not sure which is best - do it now or after glibc update.
> 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.
I am totally unfamiliar with it. I suggest that we consider this along
with the next batch of changes to gcc defaults.
> 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?
Thanks for sharing your opinion. I'll comment on this separately.
> 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).
For now, we'll enable a subset of the security options (at least
-D_FORTIFY_SOURCE=2 without a doubt has to wait for glibc update) no
matter which of these approaches we use. We've already decided to
change gcc defaults, so let's proceed to do that - grouping these
changes reasonably (what we can/should do now vs. what waits for glibc
update and for us to consider the changes more seriously).
> So, my plan for now is:
>
> 1) enable -z,relro and -z,now as gcc defaults.
ACK for -z,relro, NAK for -z,now for now. ;-) I've heard your opinion,
and we might well go for this change, but I feel that we need to discuss
this some more - in the proper thread.
> 2) enable -fexceptions in rpmmacros.
Why not postpone this for next batch? And plan to better understand it
by then.
> 3) upgrade glibc (this is a separate subject).
>
> 4) enable D_FORTIFY_SOURCE, PIE, SSP as gcc defaults.
Maybe try SSP now?
> 5) look what specs should have these security options disabled.
> (Probably do it during all 1-4 phases.)
You mean for speed? I think only PIE and -z,now are candidates to be
disabled in a few packages - e.g., PIE probably makes bzip2 a lot slower
on i686 (we even link libbz2 statically into bzip2 in order for it to
benefit from the faster position-dependent code).
* Fri Feb 01 2002 Solar Designer <solar-at-owl.openwall.com> 1.0.2-owl1
...
- Package the bzip2 binary that is statically-linked against libbz2 for
better performance on register-starved architectures such as the x86.
I think I measured a speed difference of a few percent at the time, but
we'll need to re-test this for PIE.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
