On Mon, Jun 5, 2017 at 1:35 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Jun 5, 2017 at 4:58 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Mon, Jun 5, 2017 at 1:16 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > >> > >> On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> > Amit Kapila <amit.kapil...@gmail.com> writes: > >> > > >> >> 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. > >> > > >> > >> I could not find anything directly in specs which could prove the > >> theory either way. However, in one of the StackOverflow discussions, > >> it has been indicated that MapViewOfFile can opt to load the image at > >> an address different than the predefined address due to ASLR. > >> > >> > 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. > >> > > >> > >> Sure. I think it is slightly tricky because specs don't say clearly > >> how ASLR can impact the behavior of any API and in my last attempt I > >> could not reproduce the issue. > >> > >> I can try to do basic verification with the patch you have proposed, > >> but I fear, to do the actual tests as suggested by you is difficult as > >> it is not reproducible on my machine, but I can still try. > >> > >> > >> [1] - > >> https://stackoverflow.com/questions/9718616/what-does- > mapviewoffile-return/11233456 > >> Refer below text: > >> > >> "Yes, MapViewOfFile returns the virtual memory base address where the > >> image has been loaded. The value (content) of this address depends on > >> whether the image has been successfully loaded at its predefined > >> address (which has been setup by the linker) or whether the image has > >> been relocated (because the desired, predefined address is already > >> occupied or because the image has opt-in to support ASLR)." > >> > > > > That statements refers to mapping executables though, like DLL and EXE. > Not > > mapping of data segments. > > > > It does randomize the entire location of the heap, in which case it might > > also change. But not for the individual block. > > > > But in neither of those cases does it help to retry without restarting > the > > process, > > > > Okay, the question here is do we need some handling during reattach > operation where we do MapViewOfFileEx at the predefined location? > > As long as we restart in a new process, I don't think so. ASLR does not randomize away our addresses *after we've been given them*. It does it at process (or thread start), so as long as we get it initially, I think we are safe. (Obviously nobody can be 100% sure without seeing the source code for it, but all references I've seen to the implementation seem to indicate that) -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
