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

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.

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com