Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) - Mailing list pgsql-hackers
From | Magnus Hagander |
---|---|
Subject | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) |
Date | |
Msg-id | CABUevExayB6RYXfgdCmDVqRKK3eu3Dy4tnfMAzxhBacja6m9AQ@mail.gmail.com Whole thread Raw |
In response to | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) (Amit Kapila <amit.kapila16@gmail.com>) |
List | pgsql-hackers |
On Mon, Jun 5, 2017 at 1:35 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
-- Okay, the question here is do we need some handling during reattachOn Mon, Jun 5, 2017 at 4:58 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jun 5, 2017 at 1:16 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > Amit Kapila <amit.kapila16@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,
>
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)
pgsql-hackers by date: