On Wed, Apr 19, 2017 at 9:01 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-04-19 10:15:31 -0400, Tom Lane wrote:
>> Amit Kapila <amit.kapila16@gmail.com> writes:
>> > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> Obviously, any such fix would be a lot more likely to be reliable in
>> >> 64-bit machines. There's probably not enough daylight to be sure of
>> >> making it work in 32-bit Windows, so I suspect we'd need some retry
>> >> logic anyway for that case.
>>
>> > Yeah, that kind of thing can work assuming we don't get conflicts too
>> > often, but it could be possible that conflicts are not reported from
>> > ASLR enabled environments because of commit 7f3e17b4.
>>
>> Right, but Andres' point is that we should make an effort to undo that
>> hack and instead allow ASLR to happen. Not just because it's allegedly
>> more secure, but because we may have no choice in future Windows versions.
>
> FWIW, I think it *also* might make us more secure, because addresses in
> the postgres binary won't be predictable anymore.
>
Agreed. I have done some further study by using VMMap tool in Windows
and it seems to me that all 64-bit processes use address range
(0000000000010000 ~ 000007FFFFFE0000). I have attached two screen
shots to show the address range (lower range and upper range). You
need to refer the lower half of the window in attached screenshots.
At this stage, I am not completely sure whether we can assume some
address out of this range to use in MapViewOfFileEx. Let me know your
thoughts.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
