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

From Thomas Munro
Subject Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?
Date
Msg-id CA+hUKGJOGW+03Ym8VafGk4VO1821+=8izSmp82182Ve21RHscg@mail.gmail.com
Whole thread Raw
In response to Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Aug 12, 2021 at 1:45 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I think that worked for me on older macOS releases, and then it
> stopped working at some point after some update or reinstall or
> something. Unfortunately I don't know any more precisely than that,
> but it does seem like we have to find some other approach to work on
> modern systems.

I gave up on trying to make that work once I realised that
/usr/lib/dyld doesn't seem to obey the flag, so although other
segments become deterministic and the success rate is fairly high,
there's still a 600kb wrecking ball swinging around.  I wondered what
the "slide" range could be... it appears to be fairly small
(vm_map_get_max_aslr_slide_pages() seems to be the place that's
determined and it's a 16MB or 256MB window, depending on architecture,
if I read that right).  Given that, the death of 32 bit processes
since Catalina, and the typical layout we see, I think just doing
something like (/me rolls dice) export PG_SHMEM_ADDR=0x80000000000 is
a good candidate for something that works on both architectures, being
many TB away from everything else (above everything on ARM, between
heap etc and libs on Intel but with 8TB of space below it and 120TB
above).  That gets the tests passing consistently with unpatched
master, -DEXEC_BACKEND, on both flavours of silicon.



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Use extended statistics to estimate (Var op Var) clauses
Next
From: Alvaro Herrera
Date:
Subject: Re: Autovacuum on partitioned table (autoanalyze)