Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 5 Nov 2011 19:21:24 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: %optflags for new gcc

On Fri, Nov 04, 2011 at 02:03:16PM +0400, Vasiliy Kulikov wrote:
> On Fri, Nov 04, 2011 at 04:37 +0400, Solar Designer wrote:
> > 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.

I think this is an error in the documentation.  It also says:

"Starting with GCC version 4.6, the default setting (when not optimizing
for size) for 32-bit Linux x86 and 32-bit Darwin x86 targets has been
changed to -fomit-frame-pointer."

Notice the "when not optimizing for size" remark.  Feel free to test and
submit a documentation patch upstream (removing ", -Os" from the list).

> > 3. -Wl,-z,relro
> 
> Fedora does partial RELRO by default, so it should be sane:

Sure.  Also note this comment:

http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html

"Recent Linux distris have partial RELRO enabled by default (e.g. Ubuntu
8.10 and openSUSE 11.1). There is therefore no difference between "gcc
testcase.c" and "gcc -Wl,-z,relro testcase.c" on these platforms."

To me, it seems to imply that they patched gcc or binutils to make
"-z relro" the default.  Perhaps we need to do the same?  (For now, I
added -Wl,-z,relro to our %optflags*.)

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

Oh, I had overlooked the fact that glibc 2.4+ provides those symbols.

It is possible to build with -fstack-protector with our glibc 2.3.6 as
well if we pass this option not only at compile time, but also at link
time.  I think the program gets linked against gcc's libssp.a then,
which we package, but Fedora does not:

http://pkgs.fedoraproject.org/gitweb/?p=gcc.git;a=blob;f=gcc.spec;h=5801bce771c190642657c38e8703b207f42d7765;hb=HEAD

1497 # Remove binaries we will not be including, so that they don't end up in
1498 # gcc-debuginfo
1499 rm -f %{buildroot}%{_prefix}/%{_lib}/{libffi*,libiberty.a}
1500 rm -f $FULLEPATH/install-tools/{mkheaders,fixincl}
1501 rm -f %{buildroot}%{_prefix}/lib/{32,64}/libiberty.a
1502 rm -f %{buildroot}%{_prefix}/%{_lib}/libssp*
1503 rm -f %{buildroot}%{_prefix}/bin/gappletviewer || :
1504 rm -f %{buildroot}%{_prefix}/bin/%{_target_platform}-gcc-%{version} || :
1505 rm -f %{buildroot}%{_prefix}/bin/%{_target_platform}-gfortran || :
1506 rm -f %{buildroot}%{_prefix}/bin/%{_target_platform}-gccgo || :
1507 rm -f %{buildroot}%{_prefix}/bin/%{_target_platform}-gcj || :

Note line 1502.  Perhaps we should similarly stop packaging libssp.*
after we update glibc.  And perhaps we shouldn't waste time trying to
pass -fstack-protector at link time now since this won't be needed once
we update glibc.

> FWIW, musl is not yet compilable with SSP too:
> 
> http://www.openwall.com/lists/musl/2011/05/04/2

I think it would compile with a gcc install including libssp.

And it's a curious comment that "some vendors have patched the gcc to
make this option default" (regarding -fstack-protector).  Do you know
any examples?  Maybe Ubuntu (just a guess)?

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

Why?  What problem would we have if we don't?

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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