Обсуждение: PostgreSQL and ASLR on Linux
<div class="WordSection1"><p class="MsoNormal">Hi. Has anyone had experience building PostgreSQL to support Address SpaceLayout 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 (around50%, much more than I expected). This was on 64-bit Linux x86.<p class="MsoNormal"> <p class="MsoNormal">Google turnsup some references to the Ubuntu distribution of version 8.3 being built this way but nothing much more interesting.<pclass="MsoNormal"> <p class="MsoNormal">I’d appreciate any information or help anyone can give me on this. Thanks.<p class="MsoNormal"> <p class="MsoNormal"> <p class="MsoNormal"> </div>
On Wed, Jul 31, 2013 at 4:35 PM, Robert Lerche (rlerche) <rlerche@cisco.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. > > Google turns up some references to the Ubuntu distribution of version 8.3 > being built this way but nothing much more interesting. > > I’d appreciate any information or help anyone can give me on this. Thanks. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2013-08-04 20:33:50 -0400, Robert Haas wrote: > On Wed, Jul 31, 2013 at 4:35 PM, Robert Lerche (rlerche) > <rlerche@cisco.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. What benchmark did you run? Did you run a profile? I am not really surprised that compiling the backend itself as position independent code has a high price. There's lots of switch/jump tables in pg that are called in hot paths. Adding math to those will have a price. > > Google turns up some references to the Ubuntu distribution of version 8.3 > > being built this way but nothing much more interesting. > > > > I’d appreciate any information or help anyone can give me on this. Thanks. > > 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. ALSR for code can only happen if code is built as position independent code, otherwise addresses are hardcoded. That is - in modern unixoid systems - nearly always the case for shared libraries et al, but not necessarily for plain binaries or statically linked code. The above referenced -fPIC and -pie make the code/executable position independent. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Sun, Aug 4, 2013 at 8:54 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> 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. > > ALSR for code can only happen if code is built as position independent > code, otherwise addresses are hardcoded. That is - in modern unixoid > systems - nearly always the case for shared libraries et al, but not > necessarily for plain binaries or statically linked code. The above > referenced -fPIC and -pie make the code/executable position independent. Ah, for code, yeah, I suppose that would be true. In the case I mentioned though, though, it definitely seemed that other things were moving around each time through, particularly the stack. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2013-08-04 21:07:02 -0400, Robert Haas wrote: > On Sun, Aug 4, 2013 at 8:54 PM, Andres Freund <andres@2ndquadrant.com> wrote: > >> 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. > > > > ALSR for code can only happen if code is built as position independent > > code, otherwise addresses are hardcoded. That is - in modern unixoid > > systems - nearly always the case for shared libraries et al, but not > > necessarily for plain binaries or statically linked code. The above > > referenced -fPIC and -pie make the code/executable position independent. > > Ah, for code, yeah, I suppose that would be true. In the case I > mentioned though, though, it definitely seemed that other things were > moving around each time through, particularly the stack. Oh, yes. Those just don't require PIE executables, so you can see the problem independently and to my knowledge their price is far lower. I personally think that that property/requirement of EXEC_BACKEND is going to come from behind and bite us hard... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jul 31, 2013 at 4:35 PM, Robert Lerche (rlerche) > <rlerche@cisco.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