Jakub Jelinek (jakub(a)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