[fedora-arm] Include prelink in fedora arm?

[Jon]

We like randomized addresses, improves security so exploit code cannot
anticipate the address.
Prelinked address might improve startup speed, but I'm not convinced the
speedup is worth the risk.
I believe even when sysctl is set to randomize address space, prelink will
still effect normalized addresses.

Also, there are questions about the actual speedup.

I feel prelink should be disabled in fedora completely.

However, updating the package is still desirable for resolving dependencies.


-Jon


On Tue, Sep 6, 2011 at 12:14 PM, Gordan Bobic <gordan at bobich.net> wrote:

>  On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil
>  <jan.kratochvil at redhat.com> wrote:
> > On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
> >>  Can you elaborate as to why? My experience and measurements show
> >> that
> >>  prelink does more harm than good more offten than not. I can think
> >> of a
> >>  lot of reasons to not use it, and very few reasons to use it.
> >
> > It speeds up the program startup up to 50% (you can Google out
> > various
> > benchmarks).
>
>  I did, and found no definitive, reproducible results to support the 50%
>  claim. It certainly wasn't corroborated by my own measurements - last
>  time I tested what benefit it gives, the results were at best
>  inconclusive.
>
> > As almost any performance feature it sure comes with more
> > complexity of the ELF files handling.  The most easy ELF files
> > processing
> > would be with -O0 code - so why do we build the programs with -O2?
> >
> > Nowadays some people do not consider performance as anything to care
> > about so
> > in such case it is understandable they do not see a need for prelink.
>
>  The only performance claims that are worth listening to are the ones
>  supported by evidence showing consistent and reproducible improvement -
>  and I have seen no such thing to support prelink recently.
>
>  And I just thought of another reason to not use prelink, in addition to
>  tripwire/IDS issues and vserver's hashify feature - flash media.
>  Rewriting a large chunk of your binaries on a semi-regular basis isn't
>  going to help the longevity of a system running off cheap flash media,
>  as most ARMs are doing.
>
> > It is true that if program is written in C it is usually fast enough.
> > But specifically ARM may be the only popoular platform where I do not
> > find the C programs fast enough, though.
>
>  If we're going to argue the performance toss, rewriting yum in C would
>  be a good start toward addressing the eyewateringly big performance
>  issues. Compared to that, anything that prelink could possibly achieve
>  gets lost in the noise.
>
>  To summarize - I'm unconvinced of the benefits of prelink. But I will
>  happily be persuaded otherwise by reasonably broad and repeatable
>  empirical evidence.
>
>  Gordan
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
>



-- 

-Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/arm/attachments/20110906/610bfa86/attachment.html