Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Feb 2012 13:25:19 +0400
From: Solar Designer <>
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:

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

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



Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ