Re: Re: windows 8 RTM compatibility issue (could not reserve shared memory region for child)

On Fri, Jul 5, 2013 at 1:12 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> Hi Dave,
>
> On Tue, Sep 04, 2012 at 11:45:47PM -0400, Dave Vitek wrote:
>> LOG: could not reserve shared memory region (addr=0000000001410000) for child
>> 0000000000000F8C: 487
>> LOG: could not fork new process for connection: A blocking operation was
>> interrupted by a call to WSACancelBlockingCall.
>
>> So why hasn't this ever happened before? I'm guessing that ASLR got
>> better in the latest windows 8 patch, or maybe there's just more stuff
>> in the virtual address space of a newborn process.
>
>> One straightforward "fix" is to specify a hardcoded address to
>> MapViewOfFileEx instead of NULL. This address should be carefully
>> selected such that it is in an area disjoint from the portions of the
>> address space that are potentially reserved in a newborn process, and
>> also unlikely to be in use inside the postmaster when it first maps the
>> shared memory. This is pretty trivial to do for a particular
>> version/configuration of Windows. However, I see no future-proof
>> solution (besides making the shared segment position independent). If
>> the hardcoded address is not available, you can always fall back on the
>> current behavior.
>
> Given the strong dedication to backward-compatibility in Windows, I would
> expect a way to bypass the new ASLR measures. Some web searching suggests
> linking postgres.exe with "/highentropyva:no" and/or "/dynamicbase:no" might
> help, but nothing conclusive. Thoughts? That would be preferable to relying
> on experimentally-derived safe addresses, which could cease to be safe after a
> mere Windows update or similar.
>
>> There is a security problem with the fix I outline above. It bypasses
>> ASLR to a limited degree, since the shared memory would likely end up
>> always living at the same address. I am not certain that MapViewOfFile
>> even tries to be unpredictable, but let's assume it does or will be
>> someday.
>
> I wouldn't worry about it too much. ASLR is a defense-in-depth measure; it
> comes into play when your software already has a flaw and potentially reduces
> the impact of that flaw.
>
>> I've attached a patch that implements the stuff above. I can share the
>> code for the program that tests whether an address is reliably available
>> in a newborn postgres process, if anyone is interested.
>
> Great detective work. Seeing that program could be helpful.

(reviving this old thread)

So, it happens that it is still possible to hit this issue on at least
Win2k12 boxes (received some complaints about that) even if
RandomizedBaseAddress is disabled in build, as per a result of the
following thread:
http://www.postgresql.org/message-id/BD0D89EC2438455C9DE0DC94D36912F4@maumau

This has happened on a box that was surely running with more than 125
connections (https://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#I_cannot_run_with_more_than_about_125_connections_at_once.2C_despite_having_capable_hardware)
and I am sure that it was not using more than 512MB of shared_buffers.

I am wondering if Perhaps we could do better than what we have now
with a retry logic in the thread fork loop as it seems like a stopover
to use a non-NULL lpBaseAddress in MapViewOfFileEx to make the address
selection more random as this base address selection would be
system-dependent.
Thoughts?
--
Michael