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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
