Andres Freund <and...@anarazel.de> writes:
> On 2017-04-20 16:57:03 +0530, Amit Kapila wrote:
>> 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.
> That seems like a fairly restricted range (good!), and squares with
> memories of reading about this (can't find the reference anymore). Just
> using something like 0x00000F0000000000 as the address might work
> sufficiently well. What happens if you just hardcode that in the first
> MapViewOfFileEx call, and change RandomizedBaseAddress="FALSE" in
> src/tools/msvc/VCBuildProject.pm to true?
The material I found about Linux x86_64 addressing explains that the
underlying hardware address space is only 48 bits. Linux chooses to
normalize this by sign-extending into the upper 16 bits, so that
valid 64-bit addresses are
0000000000000000 .. 00007FFFFFFFFFFF
and
FFFF800000000000 .. FFFFFFFFFFFFFFFF
If I'm counting the bits correctly, Windows is choosing to use only
1/16th of the lower half of the available address space, which seems
a bit odd. However, the main point here is that there should be
quite a bit of available daylight, if they will let us use addresses
above 000007FFFFFE0000 at all. I'd be inclined to do our own low-tech
ASLR by using addresses with a random component, say 00000Fxxxxxx0000.
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
