Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?

On Wed, Aug 11, 2021 at 6:24 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Thu, Aug 12, 2021 at 1:45 AM Robert Haas <robertmhaas(at)gmail(dot)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.

Ugh, OK. So, is there a way that we can get an "easy button" committed
to the tree?

--
Robert Haas
EDB: http://www.enterprisedb.com