Amit Kapila <amit.kapil...@gmail.com> writes:
> On Mon, Jun 5, 2017 at 4:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I took a quick look at this, and it seems rather beside the point.
> What I understood from the randomization shm allocation behavior due
> to ASLR is that when we try to allocate memory (say using
> VirtualAllocEx as in our case) at a pre-defined address, it will
> instead allocate it at a different address which can lead to a
> collision.
No. The problem we're concerned about is that by the time we try
pgwin32_ReserveSharedMemoryRegion's call
VirtualAllocEx(hChild, UsedShmemSegAddr, UsedShmemSegSize,
MEM_RESERVE, PAGE_READWRITE)
in the child process, something might have already taken that address
space in the child process, which would cause the call to fail not just
allocate some randomly different space. That can't happen unless the base
executable, or ntdll.dll, or possibly something injected by an antivirus
product, has taken up address space different from what it took up in the
postmaster process. What we are assuming here is that any such variation
is randomized, and so will probably be different in the next child process
launched by the postmaster, allowing a new process launch to possibly fix
the problem. But once that address space is allocated in a given process,
no amount of merely retrying a new allocation request in that process is
going to make it go away. You'd have to do something to free the existing
allocation, and we have no way to do that short of starting over.
> I think the same problem can happen during reattach as well.
> Basically, MapViewOfFileEx can fail to load image at predefined
> address (UsedShmemSegAddr).
Once we've successfully done the VirtualAllocEx call, that should hold
until the VirtualFree call in PGSharedMemoryReAttach, allowing the
immediately-following MapViewOfFileEx call to succeed. Were that not the
case, we'd have had problems even without ASLR. We did have problems
exactly like that before the pgwin32_ReserveSharedMemoryRegion code was
added. So my feeling about this is that retrying the process creation as
in my prototype patch ought to be sufficient; if you think it isn't, the
burden of proof is on you.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
