enable PIE by default on Linux for full ASLR

[thestinger]

Rust already builds all code as position independent by default, so the
linker can be told to build a position independent executable if it's
not disabled with -C relocation-model=dynamic-no-pic. Position
independent code does have a significant cost on i686 (not on x86_64 or
ARM) but there's no significant cost to linking code that's already
position independent as a position independent executable.

Address space layout randomization makes exploiting vulnerabilities much
more difficult by providing a statistical defence against an attempt to
find or modify existing code / data. Without ASLR, it's trivial to use a
vulnerability to take over control of the process via return-oriented
programming.

Rust code can be used for return-oriented programming whether it is safe
or unsafe, so even a fully safe application needs to be built as a
position independent executable to defend against vulnerabilities in
unsafe blocks or C libraries.

Sample program:

extern crate libc;

use std::mem;

static mut global: u32 = 5;
static constant: u32 = 5;
fn foo() {}

fn main() {
    let local = 5;
    println!("stack: {}, global: {}, constant: {}, fn: {}, lib fn: {}",
             &local as *const u32,
             unsafe { &global as *const u32 },
             &constant as *const u32,
             unsafe { mem::transmute::<_, *const ()>(foo) },
             unsafe { mem::transmute::<_, *const ()>(libc::mprotect) });
}

Before:

stack: 0x3ff15eb9f94, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x32749547530
stack: 0x3b5d47d80e4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x394469a7530
stack: 0x3fe2c4e5564, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x399734a2530
stack: 0x3e525e0fb24, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2f62a810530
stack: 0x3b50fb3eae4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2e590e86530

After:

stack: 0x38cf12c90a4, global: 0x3e2d46b488, constant: 0x3e2d23cf80, fn: 0x3e2d1c2510, lib fn: 0x2617d3b4530
stack: 0x3d733faf474, global: 0x7eb1839488, constant: 0x7eb160af80, fn: 0x7eb1590510, lib fn: 0x32d30c1f530
stack: 0x3bb42212ec4, global: 0x5bbb365488, constant: 0x5bbb136f80, fn: 0x5bbb0bc510, lib fn: 0x3595e6c1530
stack: 0x39f678c1ab4, global: 0x22c4e3c488, constant: 0x22c4c0df80, fn: 0x22c4b93510, lib fn: 0x3835b727530
stack: 0x3afb25bd394, global: 0x493eab2488, constant: 0x493e883f80, fn: 0x493e809510, lib fn: 0x3478d6a7530

This may also be necessary on other platforms, but I can only test on
Linux right now. Note that GDB gained support for debugging position
independent executables in version 7.1 (March 2010).

[KevinKelley]

Does this mean (it seems to) that linking to arbitrary pre-compiled C libraries is no longer supported, unless they had been compiled with -fPIC?

My nanovg-rs library has been breaking since this; and reddit discussion suggests that glfw-rs has as well. Both of these are fixable, no big deal.

But what about (say) linking to proprietary code supplied as .a archives, where rebuilding may not be possible? I don't have a big problem here, but was this well-thought, or is it a case of just trying something because it sounds good?

[thestinger]

Does this mean (it seems to) that linking to arbitrary pre-compiled C libraries is no longer supported, unless they had been compiled with -fPIC?

Linking to arbitrary static C libraries is still supported. Since Rust is using full ASLR by default, those libraries need to be compiled with either -fPIE or -fPIC. An alternative is passing -C relocation-model=dynamic-no-pic to disable ASLR if you don't care about security.

But what about (say) linking to proprietary code supplied as .a archives, where rebuilding may not be possible? I don't have a big problem here, but was this well-thought, or is it a case of just trying something because it sounds good?

ASLR is not just something that "sounds good". It's an important exploit mitigation even for a memory safe language like Rust, because there's a significant amount of code in unsafe blocks and C libraries. You can still choose to build without support for ASLR.

[KevinKelley]

Okay, I think I understand well enough to agree that this is a good thing. My frustration is more of a meta-comment: that I found out only when my code was broken, and it took a few days, and tracking the signs from others who were also broken, to figure out what happened.

I get that Rust is pre-release, and expect breaks. There will always be changes, I hope. I want there to be a process. In the morning I download the nightly, and rebuild; then sometimes I have to go haring off on side-trips to find out what I didn't see coming; and it's not always very clear.

[brson]

@thestinger Insinuating that somebody who needs to disable ASLR doesn't care about security is insulting. This change had a lot of unexpected fallout.

@KevinKelley thank you for your comments.

[thestinger]

@brson: I was just pointing out that's there's an easy escape hatch for projects where security isn't a concern. You don't ever need to disable it, you can build the static C libraries with -fPIE. A static library not built as fully position independent (-fPIC) can't be included in a dynamic library either so it's already problematic in many cases.

It's a problem specific to a subset of Linux distributions as the official compilers on Windows and OS X always build position independent code by default. Security-aware distributions build position independent code with their compilers too.