Ticket #1183 (closed task: fixed)

Opened 6 months ago

Last modified 6 months ago

Don't enable prelink by default in Fedora

Reported by: halfie Owned by:
Priority: major Keywords: meeting
Cc: fweimer, zbyszek, fche, michich, jankratochvil, jakub, kzak Blocked By:
Blocking:

Description

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)
  • "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

Change History

comment:1 Changed 6 months ago by fweimer

  • Cc fweimer added

comment:2 Changed 6 months ago by zbyszek

  • Cc zbyszek added

comment:3 Changed 6 months ago by fche

  • Cc fche added

comment:4 Changed 6 months ago by michich

  • Cc michich added

comment:5 Changed 6 months ago by mattdm

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)

comment:6 Changed 6 months ago by jankratochvil

  • Cc jankratochvil added

comment:7 Changed 6 months ago by pwouters

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

comment:8 in reply to: ↑ description ; follow-up: ↓ 10 Changed 6 months ago by mitr

Replying to 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.)

comment:9 Changed 6 months ago by mitr

  • Cc jakub added

comment:10 in reply to: ↑ 8 ; follow-up: ↓ 11 Changed 6 months ago by halfie

Replying to mitr:

Replying to 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!

comment:11 in reply to: ↑ 10 ; follow-up: ↓ 12 Changed 6 months ago by jankratochvil

Replying to halfie:

Replying to mitr:

Replying to 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.

comment:12 in reply to: ↑ 11 Changed 6 months ago by halfie

Replying to jankratochvil:

Replying to halfie:

Replying to mitr:

Replying to 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).

comment:13 Changed 6 months ago by kzak

  • Cc kzak added

comment:14 Changed 6 months ago by toshio

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.

comment:15 Changed 6 months ago by kevin

  • Keywords meeting added

Adding meeting keyword.

comment:16 Changed 6 months ago by pjones

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

comment:17 Changed 6 months ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

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

comment:18 Changed 6 months ago by notting

Was this intended to be F21 only?

comment:19 Changed 6 months ago by kevin

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

comment:20 Changed 6 months ago by halfie

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

comment:21 Changed 6 months ago by sgallagh

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.

comment:22 Changed 6 months ago by pcfe

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

comment:23 follow-up: ↓ 24 Changed 6 months ago by notting

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

comment:24 in reply to: ↑ 23 Changed 6 months ago by fche

Replying to 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.

comment:25 Changed 6 months ago by misc

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.

Note: See TracTickets for help on using tickets.