Expanding the list of "Hardened Packages"

Bill Nottingham notting at redhat.com
Thu Apr 4 18:54:54 UTC 2013


Jakub Jelinek (jakub at redhat.com) said: 
> On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote:
> > > A prelinked module reduces time spent in ld-linux, and increases sharing
> > > of pages (which reduces time spent in kernel duplicating copy-on-write pages.)
> > > The savings are *visible* when invoking an interactive GUI program that has
> > > dozens of shared libraries, or when several hundred smaller executables
> > > are invoked each second, such as some 'make' clouds, etc.
> > 
> > not noticeable compared with the security flaws
> 
> Security flaws?  Security flaws are the bugs that can be exploited, you are
> clearly overestimating the role of ASLR (especially when on some targets
> like x86_64 there is a fixed address syscall+ret instruction mapped into
> every process anyway), it is just one of the many mitigating factors.
> Shared libraries loaded by a PIE are ignoring prelink chosen addresses,
> so they are fully randomized each time, and network facing daemons or suid
> apps should be built that way.  But, for other binaries, PIE is way too
> costly (even when say on x86_64 the PIC register setup is basically for
> free, there is the significant cost of one extra indirection level) and when
> the binary isn't randomized, you can always return to the binary as opposed
> to shared libraries.
> If you don't care about the speed of execution of any programs, just compile
> everything with -fsanitize=address (that will be only ~ 2x slowdown or so).

My concern is simply that prelink was (theoretically) sold as a mechanism
to speed up the start of large, complex, GUI programs. Unfortuantely, most
of the large, complex, GUI programs are the ones that are parsing untrusted
content, and therefore make the most sense for PIE compilation.

Bill


More information about the devel mailing list