Re: Question regarding "The Shellcoder's Handbook"

["Andrew R. Reiter" <arr () watson org>]

Hi Avri,

On Thu, 2 Jun 2005, Avri wrote:

:Hello Dave,
:
:"In the event of an allocation (by a call to RtlAllocateHeap asking
:for 260 bytes of memory, for example) the FreeList[0].Flink and
:FreeList[0].Blink pointers are updated to point to the next free block
:that will be allocated"
:
:Could you please explain why FreeList[0] gets updated?
:

I don't mean to say I am any sort of expert on NT's crazed heap management 
system, nor an expert on "correct" (hah, correct) heap management systems, 
but from what experience I do have on implementing my own, I would have to 
say that they probably do this for possibly a number of reasons, but I 
figure it's due to the fact that they keep look aside lists to help 
improve heap allocation performance.  There are list_s_ to help suport 
multithreaded programming -- the idea of being able to allocate an object 
out of the heap without the heap manager having to hold a lock (mutex, et 
al) on the list of free objects.  I assume FreeList[0] is for the parent 
process/thread; possibly if another thread was created, FreeList[n] would 
be used in that thread.  But the idea for the FreeList[] being updated is 
that they keep a cache of chunks of memory ready for use.  When a 
proc/thread allocates a block of memory and the heap manager deems that a 
"chunk of memory" is now either no longer able to share itself (ie., give 
up more memory to another allocation -- that is, it meets some pre-defined 
low watermark), then the manager says "ok, we need to get to the next best 
free chunk of memory that can be used, hence the updating of pointers.

Many times in systems like this, they also provide the functionality where 
if that FreeList contains only N chunk (of memory) objects, and N meets 
yet another low watermark, it will allocate more chunks from another area 
(acquiring the global lock on the heap) and insert them intot he FreeList 
to, once again, help out in speed of heap allocation.

Don't hold me to this :-)  I've done a thread safe implementation of a 
"zone" like allocator for userland and done a similar system with 
per-thread FreeList's and "in use" lists to speed things up... so it kind 
of makes sense to me.

However, if the question was more towards "why 260 bytes?" then, I can't 
help :-)  

Cheers,
Andrew

 --
Andrew R. Reiter
arr () watson org
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave