Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Feb 2014 14:28:44 +0000
From: Stuart Henderson <stu@...cehopper.org>
To: oss-security@...ts.openwall.com
Cc: "CERT(R) Coordination Center" <cert@...t.org>
Subject: Re: Vendor adoption of PIE INFO#934476 oss-security

On 2014/02/16 01:03, Solar Designer wrote:
> Hi Will and all,
> 
> On Tue, Feb 11, 2014 at 04:37:21PM -0500, CERT(R) Coordination Center wrote:
> > Thoughts?  What is stopping you from enabling PIE for everything, at
> > least on the x86_64 platform?
> 
> Laziness, other priorities.  We should do it.
> 
> There might be examples of runtime generated (JIT) code or
> bytecode-alike caching across program invocations, where the generated
> code would reference functions/callbacks in the main program and would
> thus depend on the program staying where it was during code generation -
> but I am unaware of specific examples of that.  Anyhow, this is going to
> be very rare and it's not a reason not to build a distro's packages as
> PIE by default (exceptions may then be made).

By the way, OpenBSD has switched compilers to generating PIE code by
default on the majority of architectures, various arch's over the last
couple of releases, but as of a couple of months ago we've also done
this for i386 (x86) too, so I can give some specific examples of
where you can expect to run into problems.

On amd64 (x86_64) fallout has been mostly limited to compilers and a
couple of other programs, e.g. emacs, qemu, clisp, erlang, ghc, sbcl,
which we are building with PIE disabled.

Additionally for i386 there have been problems with register pressure
on programs with their own asm code (mostly games), in particular
code doing cpuid checks often doesn't save/restore %ebx, but there
have been some others. In one case there was code for x86 OSX which
avoids scribbling on %ebx which we've been able to borrow, and I think
there were one or two where we've switched from asm to a generic C
implementation. Of course, shared libraries already have to take
this into account so not too much trouble there.

Everything else, base system and ports, is built with PIE.
On the whole, experiences have been pretty good. Obviously there is
some performance impact but we haven't yet had any reports of this
causing major problems (though we will probably know more about this
after 5.5 is released when the average user will first see i386
packages built with PIE by default).

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

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