Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux? - Mailing list pgsql-hackers

From Andres Freund
Subject Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?
Date
Msg-id 20210806032944.m4tz7j2w47mant26@alap3.anarazel.de
Whole thread Raw
Responses Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Hi,

When testing EXEC_BACKEND on linux I see occasional test failures as long as I
don't disable ASLR. There's a code comment to that effect:

     * If testing EXEC_BACKEND on Linux, you should run this as root before
     * starting the postmaster:
     *
     * echo 0 >/proc/sys/kernel/randomize_va_space

but I don't like doing that on a system wide basis.

Linux allows disabling ASLR on a per-process basis using
personality(ADDR_NO_RANDOMIZE). There's a wrapper binary to do that as well,
setarch --addr-no-randomize.

I was wondering if we should have postmaster do personality(ADDR_NO_RANDOMIZE)
for EXEC_BACKEND builds? It seems nicer to make it automatically work than
have people remember that they need to call "setarch --addr-no-randomize make check".

Not that it actually matters for EXEC_BACKEND, but theoretically doing
personality(ADDR_NO_RANDOMIZE) in postmaster is a tad more secure than doing
it via setarch, as in the personality() case postmaster's layout itself is
still randomized...


Or perhaps we should just add a comment mentioning setarch.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Numeric x^y for negative x
Next
From: Yura Sokolov
Date:
Subject: Re: RFC: Improve CPU cache locality of syscache searches