Re: [HACKERS] OK, so culicidae is *still* broken - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] OK, so culicidae is *still* broken
Date
Msg-id 20170415213017.co7gkjlbcy44zlmw@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] OK, so culicidae is *still* broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] OK, so culicidae is *still* broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] OK, so culicidae is *still* broken  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
> >> Why doesn't Windows' ability to map the segment into the new process
> >> before it executes take care of that?
> 
> > Because of ASLR of the main executable (i.e. something like PIE).
> 
> Not following.  Are you saying that the main executable gets mapped into
> the process address space immediately, but shared libraries are not?

Without PIE/ASLR we can somewhat rely on pgwin32_ReserveSharedMemoryRegion
to find the space that PGSharedMemoryCreate allocated still unoccupied.
If the main binary also uses ASLR, not just libraries/stack/other
mappings, that's not guaranteed to be the case.

But this probably needs somebody with actual windows expertise
commenting.


> I wonder whether we could work around that by just destroying the created
> process and trying again if we get a collision.  It'd be a tad
> inefficient, but hopefully collisions wouldn't happen often enough to be a
> big problem.

That might work, although it's obviously not pretty.  We could also just
default to some out-of-the-way address for MapViewOfFileEx, that might
also work.

- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] OK, so culicidae is *still* broken
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] OK, so culicidae is *still* broken