Re: Question regarding "The Shellcoder's Handbook"

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

On Fri, 3 Jun 2005, Avri wrote:

:yes, the question was regarding the 260 bytes...
:
:Since FreeList[] has 128 entries -
:FreeList[1] used for 8 bytes allocation size,
:FreeList[2] used for 16 bytes allocation size,
:.
:.
:.
:FreeList[127] used for 1016 bytes allocation size.
:
:FreeList[0] would be used for allocations 1024 and above.
:
:Therefore 260 bytes - which are 32.5 (rounded up == 33) * 8, should
:use the dedicated FreeList[33].

*nod*; sorry, my knowledge of the NT5 heap internals was lacking.  For 
those confused regarding the 260 bytes and which lookaside list it should 
reside in, please read:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/heap3.asp

So, along with Avri, I too am confused with this listing in the book.  

Thanks for clarifying your question, Avri.

cheers,
andrew

:
:Thanks,
:Avri
:On 6/3/05, Andrew R. Reiter <arr () watson org> wrote:
:> 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
:>
:
:

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