On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
>>> 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.
>
> Could be. Does Microsoft publish any documentation about the range of
> addresses their ASLR uses?
>
I have look around to find some information to see if there is any
such address range which could be used for our purpose. I am not able
to see any such predictable address range. You might want to read the
article [1] especially the text around "What is the memory address
space range in virtual memory map where system DLLs and user DLLs
could load?" It seems to indicate that there is no such address
unless I have misunderstood it. I don't deny the possibility of
having such an address range, but I could not find any info on the
same.
> Obviously, any such fix would be a lot more likely to be reliable in
> 64-bit machines. There's probably not enough daylight to be sure of
> making it work in 32-bit Windows, so I suspect we'd need some retry
> logic anyway for that case.
>
Yeah, that kind of thing can work assuming we don't get conflicts too
often, but it could be possible that conflicts are not reported from
ASLR enabled environments because of commit 7f3e17b4.
[1] - https://blogs.msdn.microsoft.com/winsdk/2009/11/30/how-to-disable-address-space-layout-randomization-aslr/
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com