Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)
Дата
Msg-id CAA4eK1Lo3g2wnBVAhwRvqbMYDr8fJE6RBCS_fCYHneU3TwFNYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On 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,
>

Okay, the question here is do we need some handling during reattach
operation where we do MapViewOfFileEx at the predefined location?




-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)