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

From Andrew Dunstan
Subject Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?
Date
Msg-id 2caf377a-c3b4-ff5f-0ed1-97c977d71d76@dunslane.net
Whole thread Raw
In response to Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?  (Andres Freund <andres@anarazel.de>)
Responses Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 8/5/21 11:29 PM, Andres Freund wrote:
> 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.
>

If we can set it conveniently then that seems worth doing.


(Thinks: do we have non-Windows buildfarm members doing EXEC_BACKEND?)


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Mahendra Singh Thalor
Date:
Subject: Re: Support reset of Shared objects statistics in "pg_stat_reset" function
Next
From: David Rowley
Date:
Subject: Re: Use generation context to speed up tuplesorts