Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The exact layout of the memory while a process is executing is completely dependent on the platform which you're using. Consider the following test program:</p> <pre><code>#include &lt;stdlib.h&gt; #include &lt;stdio.h&gt; int main() { int stackValue = 0; int *addressOnStack = &amp;stackValue; int *addressOnHeap = malloc(sizeof(int)); if (addressOnStack &gt; addressOnHeap) { puts("The stack is above the heap."); } else { puts("The heap is above the stack."); } } </code></pre> <p>On Windows NT (and it's children), this program is going to generally produce:</p> <blockquote> <p>The heap is above the stack</p> </blockquote> <p>On POSIX boxes, it's going to say:</p> <blockquote> <p>The stack is above the heap</p> </blockquote> <p>The UNIX memory model is quite well explained here by @Sdaz MacSkibbons, so I won't reiterate that here. But that is not the only memory model. The reason POSIX requires this model is the <a href="http://linux.die.net/man/2/sbrk" rel="noreferrer">sbrk</a> system call. Basically, on a POSIX box, to get more memory, a process merely tells the Kernel to move the divider between the "hole" and the "heap" further into the "hole" region. There is no way to return memory to the operating system, and the operating system itself does not manage your heap. Your C runtime library has to provide that (via malloc).</p> <p>This also has implications for the kind of code actually used in POSIX binaries. POSIX boxes (almost universally) use the ELF file format. In this format, the operating system is responsible for communications between libraries in different ELF files. Therefore, all the libraries use position-independent code (That is, the code itself can be loaded into different memory addresses and still operate), and all calls between libraries are passed through a lookup table to find out where control needs to jump for cross library function calls. This adds some overhead and can be exploited if one of the libraries changes the lookup table.</p> <p>Windows' memory model is different because the kind of code it uses is different. Windows uses the PE file format, which leaves the code in position-dependent format. That is, the code depends on where exactly in virtual memory the code is loaded. There is a flag in the PE spec which tells the OS where exactly in memory the library or executable would like to be mapped when your program runs. If a program or library cannot be loaded at it's preferred address, the Windows loader must <em>rebase</em> the library/executable -- basically, it moves the position-dependent code to point at the new positions -- which doesn't require lookup tables and cannot be exploited because there's no lookup table to overwrite. Unfortunately, this requires very complicated implementation in the Windows loader, and does have considerable startup time overhead if an image needs to be rebased. Large commercial software packages often modify their libraries to start purposely at different addresses to avoid rebasing; windows itself does this with it's own libraries (e.g. ntdll.dll, kernel32.dll, psapi.dll, etc. -- all have different start addresses by default)</p> <p>On Windows, virtual memory is obtained from the system via a call to <a href="http://msdn.microsoft.com/en-us/library/aa366887.aspx" rel="noreferrer">VirtualAlloc</a>, and it is returned to the system via <a href="http://msdn.microsoft.com/en-us/library/aa366892.aspx" rel="noreferrer">VirtualFree</a> (Okay, technically VirtualAlloc farms out to NtAllocateVirtualMemory, but that's an implementation detail) (Contrast this to POSIX, where memory cannot be reclaimed). This process is slow (and IIRC, requires that you allocate in physical page sized chunks; typically 4kb or more). Windows also provides it's own heap functions (HeapAlloc, HeapFree, etc.) as part of a library known as RtlHeap, which is included as a part of Windows itself, upon which the C runtime (that is, <code>malloc</code> and friends) is typically implemented.</p> <p>Windows also has quite a few legacy memory allocation APIs from the days when it had to deal with old 80386s, and these functions are now built on top of RtlHeap. For more information about the various APIs that control memory management in Windows, see this MSDN article: <a href="http://msdn.microsoft.com/en-us/library/ms810627" rel="noreferrer">http://msdn.microsoft.com/en-us/library/ms810627</a> .</p> <p>Note also that this means on Windows a single process an (and usually does) have more than one heap. (Typically, each shared library creates it's own heap.)</p> <p>(Most of this information comes from "Secure Coding in C and C++" by Robert Seacord)</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload