Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Apr 2013 16:07:34 -0400
From: Rich Felker <dalias@...ifal.cx>
To: owl-dev@...ts.openwall.com
Subject: Re: PIE on x86_64

On Tue, Apr 30, 2013 at 09:36:58PM +0400, Vasily Kulikov wrote:
> Hi,
> 
> On Fri, Apr 26, 2013 at 21:48 -0400, Rich Felker wrote:
> > On Sat, Apr 27, 2013 at 02:14:05AM +0800, Pavel Labushev wrote:
> > > On Fri, 12 Apr 2013 22:26:58 +0400
> > > Solar Designer <solar@...nwall.com> wrote:
> > > 
> > > > > What are your reasons not to link executables as ET_DYN, even though
> > > > > the target CPU architecture is PC-relative?
> > > > 
> > > > I think we should start doing that, and benchmark to make sure there's
> > > > no unexpected performance drop.  Vasily?
> > > 
> > > And silence was the answer... Is it too much work? You could make -fpie
> > > and the other hardening flags compiler's built-in defaults, like it is
> > > done in Hardened Gentoo. It may be simpler and more robust than
> > > tweaking specs of every package and would set more secure defaults for
> > > anything that users might compile.
> > 
> > Unfortunately changing the compiler defaults can break things in
> > subtle ways. The most common breakage I'm aware of from making pie the
> > default occurs in packages with assembler source files that are
> > written in non-pic-compatible ways. These will turn into TEXTRELs in
> > the pie binary, which depending on the arch, may just result in heavy
> > runtime bloat (e.g. on 32-bit x86) or produce an error at link time
> > (e.g. on x86_64). I seem to recall a user running into this issue in
> > OpenSSL...
> 
> I've tried to enable PIE by default and disable it on -static, etc.

Speaking of -static, it would be nice if we could get the work I did
on static-PIE upstreamed someday..

Rich

Powered by blists - more mailing lists

Your e-mail address:

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