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

On Sun, Nov 06, 2011 at 08:23:54PM +0400, Vasiliy Kulikov wrote:
> On Sat, Nov 05, 2011 at 19:21 +0400, Solar Designer wrote:
> > 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)?
> 
> Yes, Ubuntu does.  I think we may patch ld and gcc to enable SSP and
> -z,relro by default, but explicitly pass FORTIFY_SOURCE=2 in
> spec files, which behave well with them.  
> 
> Possible problems with FORTIFY_SOURCE:
> 
> https://wiki.ubuntu.com/ToolChain/CompilerFlags#Problems

That's a good summary (the ToolChain/CompilerFlags page), thanks!

> I cannot find what wrong can happen with -z,now.  I'm finding only bug
> in ld's implementation of "-z now" :-)
> 
> 
> "ld -z now" might significantly slowdown the loading of bloated apps
> with tons of dynamic libraries like X apps (OpenOffice, Firefox, etc.).
> Given (almost?) all official Owl programs are very small in sense of
> used dynamic libraries, we probably may want to use -z,now in %optflags,
> but not change binutils' defaults.  In this case all manually compiled
> programs, which might be rather large and use numerous dynlibs, will not
> be significantly slowed down.

Yes, we might do that, although initially I thought that we'd enable
-z now per-package.

I think the slowdown could matter for programs typically run from shell
scripts, because they would often/typically use only a small subset of
library (mostly libc) functions that they have relocations for (can
potentially use), yet their startup time could significantly affect the
total run time of the script.  Also, I think it could matter for
interpreters like Perl, which are often invoked on tiny scripts that
only use a small subset of the interpreter's functionality (and thus of
library functions that it could use).  I just did some testing - to my
surprise, Perl starts up only about 10% slower when I set LD_BIND_NOW.
Yet 10% is significant for some uses - e.g., think CGI scripts written
in Perl.

Once we're done with the basics, we could also consider offering prelink
for programs where startup time is the most important factor, even
though this goes against security.  Maybe it'd make sense to let our
users (Owl install admins) build e.g. PHP with prelink (for frequent
invocation via CGI).

http://en.wikipedia.org/wiki/Prelink
http://www.gentoo.org/doc/en/prelink-howto.xml
http://www.gentoo.org/proj/en/hardened/pic-internals.xml

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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