Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Nov 2011 14:03:16 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: %optflags for new gcc

Solar,

Some of the questions need additional investigation, I'm answering now
to the part of your questions.

On Fri, Nov 04, 2011 at 04:37 +0400, Solar Designer wrote:
> On Wed, Oct 26, 2011 at 08:52:14AM +0400, Solar Designer wrote:
> > 1. Use -Os instead of -O2.  BTW, the kernel already builds with -Os.
> > In my (limited) testing, -Os results in significantly smaller code that
> > is about as fast as -O2's (and is sometimes faster than -O2's).
> 
> 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.

http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html
"-fomit-frame-pointer
...
Enabled at levels -O, -O2, -O3, -Os."

IOW, it it enabled by default on BOTH -O2 and -Os.


> 3. -Wl,-z,relro

Fedora does partial RELRO by default, so it should be sane:

http://pkgs.fedoraproject.org/gitweb/?p=redhat-rpm-config.git;a=blob;f=redhat-rpm-config-9.1.0-relro.patch;h=10c09d64350e3d820536b89141c2a7539982035c;hb=HEAD

> A. -fstack-protector needs to be passed at link time as well, and
> linking must be done via gcc as well.  Right now, this is not true for
> many of our packages.  In my test build with -fstack-protector on
> x86_64, 63 out of 153 packages failed to build, with errors like:
> 
> sysutil.o: In function `vsf_sysutil_accept_timeout':
> sysutil.c:(.text+0x1b1c): undefined reference to `__stack_chk_guard'
> sysutil.c:(.text+0x1c67): undefined reference to `__stack_chk_guard'
> sysutil.c:(.text+0x1cc6): undefined reference to `__stack_chk_fail'

http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt

"PREREQUISITES:
GCC-4.1 (or newer) for SSP and _FORTIFY_SOURCE.
***Glibc-2.4 (or newer) for SSP and _FORTIFY_SOURCE.***"

So, we need Glibc update first.


FWIW, musl is not yet compilable with SSP too:

http://www.openwall.com/lists/musl/2011/05/04/2


> B. With our current gcc.spec, gcc doesn't let us use -fstack-protector
> and -fPIE -pie at once:
...
> 5. PIE is another thing we may want to enable selectively (like "full
> RELRO") or to let our advanced users enable fully (in their rebuild of
> Owl)
...

Fedora does it by defining %_hardened_build in specs ready for hardening
flags:

http://pkgs.fedoraproject.org/gitweb/?p=redhat-rpm-config.git;a=blob;f=redhat-rpm-config-9.1.0-hardened.patch;h=007a6c15cc764d951ab94f021385fbbcd35dc7f1;hb=HEAD

We may do the same or the opposite - allow hardening flags by default and
define %_no_hardened_build in packages which are known to be broken by
SSP/RELRO or significantly slowed down.


But for bootstraping we probably should explicitly pass -fPIE to gcc in
gcc.spec.


> 6. After we update glibc, we'll want to use -D_FORTIFY_SOURCE=2.
> Somehow Fedora uses -Wp,-D_FORTIFY_SOURCE=2 - does this really matter
> or are they trying to save some CPU cycles during builds?
> 
>        -Wp,option
>            You can use -Wp,option to bypass the compiler driver and pass
>            option directly through to the preprocessor.  If option contains
>            commas, it is split into multiple options at the commas.  However,
>            many options are modified, translated or interpreted by the com-
>            piler driver before being passed to the preprocessor, and -Wp
>            forcibly bypasses this phase.  The preprocessor's direct interface
>            is undocumented and subject to change, so whenever possible you
>            should avoid using -Wp and let the driver handle the options
>            instead.

I don't see the difference between them for -D.


> 7. What's the deal with Fedora's use of -fexceptions?  Why do they do it?

from gcc(1):

"-fexceptions
Enable exception handling.  Generates extra code needed to propagate exceptions.
...
However, you may need to enable this option when compiling C code that needs to
interoperate properly with exception handlers written in C++..."


Does it add significant slowdown/stack bloating?  If not, we might want
to enable it to be binary compatible with Fedora/RHEL.

Thanks,

-- 
Vasiliy

Powered by blists - more mailing lists

Your e-mail address:

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