On Sat, 25 Mar 2017 15:39:58 -0400, rickman <
gnu...@gmail.com> wrote:
>On 3/24/2017 10:50 PM, George Neuner wrote:
>> On Fri, 24 Mar 2017 16:10:12 -0400, rickman <
gnu...@gmail.com> wrote:
>>
>> If the problem is on 64-bit, it could be address space randomization -
>> particularly if you use any home-grown extensions.
>>
>>
>> You might try turning it off:
>>
>> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
>> Management\MoveImages=dword:00000000.
>>
>> and reboot.
>>
>> But be aware that doing so lessens overall system security and could
>> cause kittens to be harmed.
>
>I'm not big on lessening system security, I would *never* do anything to
>harm a kitten and I'm not sure what "turning it off" would mean exactly.
Address space layout randomization (ASLR) is a guard against some
types of memory based exploits - particularly certain types of buffer
overruns.
When a process is executed under ASLR, the various segments of the
executable - code, data, stack, etc. - are placed at randomly selected
locations within the virtual address space of the process.
[i.e. 2 (or 3) GB for 32-bit, 2**52 bytes for 64-bit].
Note that ASLR affects only the *virtual* addresses used by program
code - physical addresses used by the CPU still are at the whim of VMM
page mapping.
If you disable ALSR globally, or an executable doesn't support it
(more below), then the OS falls back on contiguous placement of the
load segments.
[On Windows, ASLR requires that all the program's load segments must
be placed dynamically. If any segment needs an absolute address, the
program can't use ASLR. If you require ASLR globally (as a policy)
then such programs can't be run.]
ASLR makes it unlikely that any two runs of a program will use the
same addresses, so the locations of exploitable code (if any) with
respect to something a hacker can access - like an I/O buffer - will
be different every time the program executes.
On Windows, unless you enable ASLR globally, it affects only those
executables that were specifically compiled for it. However, it is
the default for 64-bit compilers, and has been available as an option
for 32-bit compilers for a long time [since 2002, IIRC]. Most
commercial 32-bit software uses it.
The problem with ASLR is that a program may depend on assumptions such
as "all heap addresses will be lower than any stack addresses". Under
ASLR, these assumptions may be violated: program segments may be
located anywhere in the address space.
Or a program may have a bug that is normally hidden, but if by chance
ASLR reorders its load segments in a particular way, the seemingly
innocuous bug turns into something fatal.
For 32-bit programs, ASLR also can impact sharing memory among
multiple processes because a particular needed address range may not
always be available. This can affect 64-bit programs too, but the
vastly larger address space makes it much more likely that a
reasonably sized block can be placed wherever you need it.
On the whole, ASLR is a good thing - but it isn't without warts.
George