Re: PostgreSQL and ASLR on Linux

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jul 31, 2013 at 4:35 PM, Robert Lerche (rlerche)
> <rlerche(at)cisco(dot)com> wrote:
>> Hi. Has anyone had experience building PostgreSQL to support Address Space
>> Layout Randomization (ASLR)? I recently took a brute-force approach
>> (compiling everything with -fPIC and specifying -pie on all executables).
>> This worked, but a (very superficial) performance test indicated a high cost
>> (around 50%, much more than I expected). This was on 64-bit Linux x86.

> AFAIK you've got it backwards: ASLR is something that happens
> automatically, unless you take steps to suppress it, at least on MacOS
> X. I not long ago built with EXEC_BACKEND on that platform and found
> that it broke stuff until I disabled ASLR.

I believe pretty much everybody applies ASLR to stack and data areas by
default, and to code in shared libraries (which have to be built with
-fPIC anyway). But you don't get ASLR on a program executable's code area
unless it's built with PIE, at least not on Linux. Also, there are some
other defenses against code-stomp attacks, like RELRO and "-z now" (early
linkage binding so the GOT can be marked readonly), which tend to be
included as well when people speak of hardened binaries.

Back when I was still wearing a red fedora, I experimented a bit with
hardening Red Hat's PG build, but I didn't get to the question of whether
it hurt performance because it flat out did not work in 32-bit builds:
https://bugzilla.redhat.com/show_bug.cgi?id=947022
Those problems wouldn't apply to a 64-bit build though.

A 50% cost sounds pretty astonishing for x86_64 --- there's no way that
people would be clamoring for enabling these methods by default (which
they are) if that were the typical penalty. The Fedora packaging
guidelines claim the only significant performance cost is loss of prelink
support, which should theoretically only affect process startup time.
If you were doing very short-term performance tests, maybe that's what
you were seeing?

regards, tom lane