#1183 Don't enable prelink by default in Fedora
Closed None Opened 10 years ago by halfie.

I am proposing that prelink should not be enabled by default in Fedora.

This proposal has already been discussed on the "security" and "devel" mailing
lists. See "prelink performance gains" thread [1] for various benchmarks and
more information. Overall, the performance gains of prelink can't be
distinguished over "background noise" in many (or even most) cases.
Additionally, there seems to be a consensus on disabling prelink by default
(from my understanding of the discussion thread).

There are some technologies which reduce the need for prelink [2]. These include:

  • Symbol visibility support, which when used properly, reduces dramatically
    the number of symbols to resolve and hence the amount of time taken to
    resolve them. Debian (and Ubuntu) already turn on this
    "-Bsymbolic-functions" flag.

  • Hash tables, which will be generated by the linker and included as a extra
    section in the ELF file, which make looking up symbols to resolve them
    nearly free.

For a summary of issues with enabling prelink, please see http://lwn.net/Articles/341244/ article. In summary,

  • It (prelink) does not play nice with checksum integrity tools (e.g. AIDE).
    It does not play nice with "rpm -V".

  • Disables ASLR for non-PIE files (for up to 2 weeks and majority of the
    binaries are non-PIE). Yes, we are already working on making setuid
    programs and network daemons use PIE but this will take time.

  • It adds complexity and fragility to Fedora (think complicated prelink blacklists,
    complicated cron job exclusion with sysconfig).

  • It (prelink) breaks FIPS mode for multiple applications.

  • Has long-standing known "direct or in-direct" bugs.

  • Other distributions do NOT enable prelink by default. "Fedora and Red Hat
    Enterprise Linux (RHEL) enable pre-linking by default, while most other
    distributions make prelink available, but seem unconvinced that the
    benefits are substantial enough to make it the default." (LWN)

  • We don't need another https://bugzilla.redhat.com/show_bug.cgi?id=509655
    sort of thing happening. "Overall, pre-linking is a bit of a hack, and it
    is far from clear that its benefits are substantial enough to overcome
    that." (LWN)

  • "Though prelink does provide a benefit, it may be a bit hard to justify as
    time goes on. For some, who are extremely sensitive to start up time costs,
    it may make a great deal of sense, but it may well be that for the majority
    of users, the annoyance and dangers are just not worth it." (LWN)

  • It has been observed that if you are low on disk space and you prelink your
    entire system then there is a possibility that your binaries may be
    truncated. The result being a b0rked system (Arch Linux Wiki).

Florian says that the performance differences (for shell-bench, see [4]) are
about the same for PPC64 when compared with AMD64 numbers.

Disabling prelink by default should be fine (unexpected things shouldn't
happen). We have already disabled prelink in Fedora live images. See [4] for
more information.

Here are the benefits of disabling prelink by default,

  • Checksum integrity and other software work as expected.

  • We get ASLR for almost all applications (by doing nothing extra!). This
    includes applications like Firefox and Evince.

  • No more "unexpected" I/O burden of running prelink from cron every day.

In summary, while prelink made sense before, it no longer does on modern
hardware. Additionally, as time goes, prelink will provide even more
diminishing results.

References:

[1] https://lists.fedoraproject.org/pipermail/devel/2013-October/

[2] https://wiki.gentoo.org/wiki/Hardened/Toolchain

[3] https://github.com/kholia/unSPEC

[4] http://tinyurl.com/desktop-drop-prelink-commit

[5] https://github.com/kholia/unSPEC/tree/master/shell-bench


Note that prelink was recently removed from the F20 desktop spin and hasn't been in the cloud image for a several releases, so "enable by default" is kind of a squishy term.

Right now, it is in the "standard" set of packages, which is one level up from the minimal install. So, there's two possible things this could mean:

  1. Remove the package from standard
  2. set "PRELINKING=no" in /etc/sysconfig/prelink by default (regardless of what groups the package may be in)

See also previous discussions:

https://fedorahosted.org/fesco/ticket/1104

https://fedorahosted.org/fesco/ticket/1113

Changing PRELINKING= to "no" is not enough. prelinking would need to be undone. If we obsolete prelink we should somehow ensure that removing it performs prelink -ua

Replying to [ticket:1183 halfie]:

There are some technologies which reduce the need for prelink [2]. These include:

  • Symbol visibility support, which when used properly reduces dramatically
    the number of symbols to resolve and hence the amount of time taken to
    resolve them. Debian (and Ubuntu) already turn on this
    "-Bsymbolic-functions" flag.
    Hypothetical, we don't do that.

  • Disables ASLR for non-PIE files (for up to 2 weeks and majority of the
    binaries are non-PIE). Yes, we are already working on making setuid
    programs and network daemons use PIE but this will take time.
    Again, this is typically not a significant decrease in security.

  • It (prelink) breaks FIPS mode for multiple applications.
    The FIPS mode requirements are technically nonsense (... but we have to do it anyway for compliance).

Disabling prelink by default should be fine (unexpected things shouldn't
happen).
Let's be honest, this is fairly equivalent to just dropping it: support for it will bitrot.

  • We get ASLR for almost all applications (by doing nothing extra!). This
    includes applications like Firefox and Evince.
    How so? Both /usr/bin/evince and /usr/lib64/firefox/firefox-bin are non-PIE, and provide plenty of code at non-randomized addresses.

(I'm not currently really opposed to the proposal; I do want the decision to be made based on correct arguments.)

Replying to [comment:8 mitr]:

Replying to [ticket:1183 halfie]:

There are some technologies which reduce the need for prelink [2]. These include:

  • Symbol visibility support, which when used properly reduces dramatically
    the number of symbols to resolve and hence the amount of time taken to
    resolve them. Debian (and Ubuntu) already turn on this
    "-Bsymbolic-functions" flag.
    Hypothetical, we don't do that.

You are right and this is hypothetical. That being said, I am working on a proposal to get this flag enabled in Fedora.

  • Disables ASLR for non-PIE files (for up to 2 weeks and majority of the
    binaries are non-PIE). Yes, we are already working on making setuid
    programs and network daemons use PIE but this will take time.
    Again, this is typically not a significant decrease in security.

The keyword is "typically". Why take chances and try your luck ;) ?

Disabling prelink by default should be fine (unexpected things shouldn't
happen).
Let's be honest, this is fairly equivalent to just dropping it: support for it will bitrot.

I think that this is a valid point. I would say that it depends on Fedora being able to find "dedicated"
folks to work on maintaining prelink, going forward. I am not sure if other distributions will send in patches for prelink.

  • We get ASLR for almost all applications (by doing nothing extra!). This
    includes applications like Firefox and Evince.
    How so? Both /usr/bin/evince and /usr/lib64/firefox/firefox-bin are non-PIE, and provide plenty of code at non-randomized addresses.

Right. Applications can have lot of main (non-library) code and disabling prelink (and getting "mutating ASLR") won't help against ret2text attacks. That being said, at least "other areas" do get ASLR benefits.
I also have patches for building Firefox (and like 40 other applications) as PIE.

Thanks for the feedback!

Replying to [comment:10 halfie]:

Replying to [comment:8 mitr]:

Replying to [ticket:1183 halfie]:

Disabling prelink by default should be fine (unexpected things shouldn't
happen).
Let's be honest, this is fairly equivalent to just dropping it: support for it will bitrot.

I think that this is a valid point. I would say that it depends on Fedora being able to find
"dedicated" folks to work on maintaining prelink, going forward. I am not sure if other distributions
will send in patches for prelink.

I do not share this opinion. prelink is a part of upstream packages support and their testsuites (at least gdb, elfutils, prelink, valgrind, maybe others) and the compatibility is maintained. There are only some user convenience issues which I was not even aware before as a prelink user. You force maintainers of toolchain to maintain their own copy of prelink - but Fedora should be convenient also for developers.

Replying to [comment:11 jankratochvil]:

Replying to [comment:10 halfie]:

Replying to [comment:8 mitr]:

Replying to [ticket:1183 halfie]:

Disabling prelink by default should be fine (unexpected things shouldn't
happen).
Let's be honest, this is fairly equivalent to just dropping it: support for it will bitrot.

I think that this is a valid point. I would say that it depends on Fedora being able to find
"dedicated" folks to work on maintaining prelink, going forward. I am not sure if other distributions
will send in patches for prelink.

I do not share this opinion. prelink is a part of upstream packages support and their testsuites (at least gdb, elfutils, prelink, valgrind, maybe others) and the compatibility is maintained. There are only some user convenience issues which I was not even aware before as a prelink user. You force maintainers of toolchain to maintain their own copy of prelink - but Fedora should be convenient also for developers.

I am glad to hear that we are in a good shape upstream. It would be also be great to address long-standing bugs while you guys are at it. One (not me) might even argue that packages in the "standard" should be well maintained to remain in "standard".

I would like to point something very obvious. Fedora is NOT the only distribution out there (we will wipe out all other distributions at some point but let's not get into that here). There are many distributions out there and obviously they have developers too. So far, these distributions haven't enabled prelink by default. Additionally, their developers are doing just fine, I haven't seen them pushing for "prelink by default", so that they can "develop" "faster". Developers are welcome to do "yum install prelink" at any time. I respect developers (I am one myself) but they should not push the "burden" of prelink on to every user by default (in my opinion).

Instead of "developing" hacks like prelink, that time is probably better spent these days on improving workflows, "configure", build steps and other essential packages. This last sentence is strictly my personal opinion and has nothing to do with this ticket (or other arguments).

I realized I probably won't be around for next week's meeting. From the discussion so far, I'd be +1 to the request to not enable prelink.

Adding meeting keyword.

I'm +1 to removing prelink from the default packageset.

AGREED: remove prelink from core and standard groups (+8,0,0)

Was this intended to be F21 only?

I read it that way, but I'm fine with doing it in f20 as well if there is enough support for that.

It would be great if we could implement this change in Fedora 20 itself.

What's the scope of implementing this change in Fedora 20? Just removing the packages from comps or do we need to run unprelink? I'm wary of making big changes now, given that we're already in Beta Freeze.

I would also welcome prelink to be off by default. Alternatively have it removed from the default package set.

Simple scope is just removing the package for new installs. Having systems unprelinked on upgrade would have to be a manual process.

Replying to [comment:23 notting]:

[...] Having systems unprelinked on upgrade would have to be a manual process.

OTOH that may be unnecessary, as an upgrade should replace most or all
binaries from new RPMs.

I would suggest to just modify comps. Anything else is going to be tricky, since you cannot decide if people want to give prelink or do not care. Those who care enough to have it removedd already have removed it, and since this is in beta, this would be simpler to just not install vs adding something in fedup and/or some strange weird conflict. We do not have a proper canonical solution for that, and I doubt we can find one until the releas( I mean, one that would be tested enough ). So just remove should be enough.

Login to comment on this ticket.

Metadata