Per migliorare l'efficienza su come i chunk sono memorizzati, ogni chunk non è solo in una lista collegata, ma ci sono diversi tipi. Questi sono i bins e ci sono 5 tipi di bins: 62 small bins, 63 large bins, 1 unsorted bin, 10 fast bins e 64 tcache bins per thread.
L'indirizzo iniziale per ciascun unsorted, small e large bins è all'interno dello stesso array. L'indice 0 è inutilizzato, 1 è l'unsorted bin, i bins 2-64 sono small bins e i bins 65-127 sono large bins.
Tcache (Per-Thread Cache) Bins
Anche se i thread cercano di avere il proprio heap (vedi Arenas e Subheaps), c'è la possibilità che un processo con molti thread (come un server web) condividerà l'heap con altri thread. In questo caso, la soluzione principale è l'uso di lockers, che potrebbero rallentare significativamente i thread.
Quando un thread libera un chunk, se non è troppo grande per essere allocato nel tcache e il rispettivo tcache bin non è pieno (già 7 chunk), verrà allocato lì. Se non può andare nel tcache, dovrà aspettare il blocco dell'heap per poter eseguire l'operazione di liberazione globalmente.
Quando un chunk è allocato, se c'è un chunk libero della dimensione necessaria nel Tcache lo utilizzerà, altrimenti, dovrà aspettare il blocco dell'heap per poter trovarne uno nei bins globali o crearne uno nuovo.
C'è anche un'ottimizzazione, in questo caso, mentre ha il blocco dell'heap, il thread riempirà il suo Tcache con chunk dell'heap (7) della dimensione richiesta, così nel caso ne avesse bisogno di più, li troverà nel Tcache.
Add a tcache chunk example
```c #include #include
int main(void) { char *chunk; chunk = malloc(24); printf("Address of the chunk: %p\n", (void *)chunk); gets(chunk); free(chunk); return 0; }
Compilalo e debugga con un breakpoint nell'operazione ret della funzione main. Poi con gef puoi vedere il tcache bin in uso:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=0, size=0x20, count=1] ← Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
Strutture e Funzioni Tcache
Nel seguente codice è possibile vedere i max bins e i chunks per index, la struttura tcache_entry creata per evitare doppie liberazioni e tcache_perthread_struct, una struttura che ogni thread utilizza per memorizzare gli indirizzi di ciascun indice del bin.
tcache_entry e tcache_perthread_struct
```c // From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c
/* We want 64 entries. This is an arbitrary limit, which tunables can reduce. */
/* With rounding and alignment, the bins are... idx 0 bytes 0..24 (64-bit) or 0..12 (32-bit) idx 1 bytes 25..40 or 13..20 idx 2 bytes 41..56 or 21..28 etc. */
/* This is another arbitrary limit, which tunables can change. Each tcache bin will hold at most this number of chunks. */
define TCACHE_FILL_COUNT 7
/* Maximum chunks in tcache bins for tunables. This value must fit the range of tcache->counts[] entries, else they may overflow. */
define MAX_TCACHE_COUNT UINT16_MAX
[...]
typedef struct tcache_entry { struct tcache_entry next; / This field exists to detect double frees. */ uintptr_t key; } tcache_entry;
/* There is one of these for each thread, which contains the per-thread cache (hence "tcache_perthread_struct"). Keeping overall size low is mildly important. Note that COUNTS and ENTRIES are redundant (we could have just counted the linked list each time), this is for performance reasons. */ typedef struct tcache_perthread_struct { uint16_t counts[TCACHE_MAX_BINS]; tcache_entry *entries[TCACHE_MAX_BINS]; } tcache_perthread_struct;
</details>
La funzione `__tcache_init` è la funzione che crea e alloca lo spazio per l'oggetto `tcache_perthread_struct`
<details>
<summary>codice tcache_init</summary>
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L3241C1-L3274C2
static void
tcache_init(void)
{
mstate ar_ptr;
void *victim = 0;
const size_t bytes = sizeof (tcache_perthread_struct);
if (tcache_shutting_down)
return;
arena_get (ar_ptr, bytes);
victim = _int_malloc (ar_ptr, bytes);
if (!victim && ar_ptr != NULL)
{
ar_ptr = arena_get_retry (ar_ptr, bytes);
victim = _int_malloc (ar_ptr, bytes);
}
if (ar_ptr != NULL)
__libc_lock_unlock (ar_ptr->mutex);
/* In a low memory situation, we may not be able to allocate memory
- in which case, we just keep trying later. However, we
typically do this very early, so either there is sufficient
memory, or there isn't enough memory to do non-trivial
allocations anyway. */
if (victim)
{
tcache = (tcache_perthread_struct *) victim;
memset (tcache, 0, sizeof (tcache_perthread_struct));
}
}
Indici Tcache
Il tcache ha diversi bin a seconda della dimensione e dei puntatori iniziali al primo chunk di ciascun indice e alla quantità di chunk per indice che si trovano all'interno di un chunk. Questo significa che localizzando il chunk con queste informazioni (di solito il primo), è possibile trovare tutti i punti iniziali del tcache e la quantità di chunk Tcache.
Fast bins
I fast bins sono progettati per velocizzare l'allocazione della memoria per chunk piccoli mantenendo i chunk recentemente liberati in una struttura di accesso rapido. Questi bin utilizzano un approccio Last-In, First-Out (LIFO), il che significa che il chunk liberato più recentemente è il primo a essere riutilizzato quando c'è una nuova richiesta di allocazione. Questo comportamento è vantaggioso per la velocità, poiché è più veloce inserire e rimuovere dalla cima di uno stack (LIFO) rispetto a una coda (FIFO).
Inoltre, i fast bins utilizzano liste collegate semplici, non doppie, il che migliora ulteriormente la velocità. Poiché i chunk nei fast bins non vengono uniti con i vicini, non c'è bisogno di una struttura complessa che consenta la rimozione dal mezzo. Una lista collegata semplice è più semplice e veloce per queste operazioni.
Fondamentalmente, ciò che accade qui è che l'intestazione (il puntatore al primo chunk da controllare) punta sempre all'ultimo chunk liberato di quella dimensione. Quindi:
Quando viene allocato un nuovo chunk di quella dimensione, l'intestazione punta a un chunk libero da utilizzare. Poiché questo chunk libero punta al successivo da utilizzare, questo indirizzo viene memorizzato nell'intestazione in modo che la successiva allocazione sappia dove ottenere un chunk disponibile
Quando un chunk viene liberato, il chunk libero salverà l'indirizzo del chunk attualmente disponibile e l'indirizzo di questo chunk appena liberato verrà messo nell'intestazione
La dimensione massima di una lista collegata è 0x80 e sono organizzate in modo che un chunk di dimensione 0x20 si trovi nell'indice 0, un chunk di dimensione 0x30 si troverebbe nell'indice 1...
I chunk nei fast bins non sono impostati come disponibili, quindi vengono mantenuti come chunk fast bin per un certo periodo invece di poter essere uniti con altri chunk liberi circostanti.
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711/*FastbinsAn array of lists holding recently freed small chunks. Fastbinsare not doubly linked. It is faster to single-link them, andsince chunks are never removed from the middles of these lists,double linking is not necessary. Also, unlike regular bins, theyare not even processed in FIFO order (they use faster LIFO) sinceordering doesn't much matter in the transient contexts in whichfastbins are normally used.Chunks in fastbins keep their inuse bit set, so they cannotbe consolidated with other free chunks. malloc_consolidatereleases all chunks in fastbins and consolidates them withother free chunks.*/typedefstruct malloc_chunk *mfastbinptr;#definefastbin(ar_ptr, idx) ((ar_ptr)->fastbinsY[idx])/* offset 2 to use otherwise unindexable first 2 bins */#definefastbin_index(sz) \((((unsignedint) (sz)) >> (SIZE_SZ ==8?4:3)) -2)/* The maximum fastbin request size we support */#defineMAX_FAST_SIZE (80* SIZE_SZ /4)#defineNFASTBINS (fastbin_index (request2size (MAX_FAST_SIZE)) +1)
Aggiungi un esempio di chunk fastbin
```c #include #include
int main(void) { char *chunks[8]; int i;
// Loop to allocate memory 8 times for (i = 0; i < 8; i++) { chunks[i] = malloc(24); if (chunks[i] == NULL) { // Check if malloc failed fprintf(stderr, "Memory allocation failed at iteration %d\n", i); return 1; } printf("Address of chunk %d: %p\n", i, (void *)chunks[i]); }
// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }
return 0; }
Nota come allochiamo e liberiamo 8 chunk della stessa dimensione in modo che riempiano il tcache e l'ottavo sia memorizzato nel fast chunk.
Compilalo e debugga con un breakpoint nell'opcode `ret` della funzione `main`. Poi con `gef` puoi vedere che il tcache bin è pieno e un chunk è nel fast bin:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=0, size=0x20, count=7] ← Chunk(addr=0xaaaaaaac1770, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1750, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1730, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1710, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac16f0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac16d0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] ← Chunk(addr=0xaaaaaaac1790, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
Fastbins[idx=1, size=0x30] 0x00
Unsorted bin
Il bin non ordinato è una cache utilizzata dal gestore della memoria per rendere più veloce l'allocazione della memoria. Ecco come funziona: Quando un programma libera un chunk, e se questo chunk non può essere allocato in un tcache o fast bin e non collide con il top chunk, il gestore della memoria non lo mette immediatamente in un bin specifico piccolo o grande. Invece, prima cerca di fonderlo con eventuali chunk liberi adiacenti per creare un blocco più grande di memoria libera. Poi, posiziona questo nuovo chunk in un bin generale chiamato "unsorted bin."
Quando un programma richiede memoria, il gestore della memoria controlla il bin non ordinato per vedere se c'è un chunk di dimensioni sufficienti. Se ne trova uno, lo utilizza immediatamente. Se non trova un chunk adatto nel bin non ordinato, sposta tutti i chunk in questa lista nei loro bin corrispondenti, sia piccoli che grandi, in base alle loro dimensioni.
Nota che se un chunk più grande viene diviso in 2 metà e il resto è maggiore di MINSIZE, verrà riposizionato nel bin non ordinato.
Quindi, il bin non ordinato è un modo per accelerare l'allocazione della memoria riutilizzando rapidamente la memoria recentemente liberata e riducendo la necessità di ricerche e fusioni che richiedono tempo.
Nota che anche se i chunk appartengono a categorie diverse, se un chunk disponibile collide con un altro chunk disponibile (anche se originariamente appartengono a bin diversi), verranno fusi.
Aggiungi un esempio di chunk non ordinato
```c #include #include
int main(void) { char *chunks[9]; int i;
// Loop to allocate memory 8 times for (i = 0; i < 9; i++) { chunks[i] = malloc(0x100); if (chunks[i] == NULL) { // Check if malloc failed fprintf(stderr, "Memory allocation failed at iteration %d\n", i); return 1; } printf("Address of chunk %d: %p\n", i, (void *)chunks[i]); }
// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }
return 0; }
Nota come allochiamo e liberiamo 9 chunk della stessa dimensione in modo che **riempiano il tcache** e l'ottavo è memorizzato nel bin non ordinato perché è **troppo grande per il fastbin** e il nono non è liberato, quindi il nono e l'ottavo **non vengono uniti con il chunk superiore**.
Compilalo e debuggalo con un breakpoint nell'operazione `ret` dalla funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel bin non ordinato:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=15, size=0x110, count=7] ← Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] unsorted_bins[0]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[+] Found 1 chunks in unsorted bin.
Small Bins
I piccoli bin sono più veloci dei grandi bin ma più lenti dei fast bin.
Ogni bin dei 62 avrà chunk della stessa dimensione: 16, 24, ... (con una dimensione massima di 504 byte in 32 bit e 1024 in 64 bit). Questo aiuta nella velocità nel trovare il bin dove dovrebbe essere allocato uno spazio e nell'inserimento e rimozione di voci in queste liste.
Questo è come viene calcolata la dimensione del piccolo bin in base all'indice del bin:
Dimensione più piccola: 2*4*indice (ad es. indice 5 -> 40)
Dimensione più grande: 2*8*indice (ad es. indice 5 -> 80)
// Loop to allocate memory 8 times for (i = 0; i < 9; i++) { chunks[i] = malloc(0x100); if (chunks[i] == NULL) { // Check if malloc failed fprintf(stderr, "Memory allocation failed at iteration %d\n", i); return 1; } printf("Address of chunk %d: %p\n", i, (void *)chunks[i]); }
// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }
chunks[9] = malloc(0x110);
return 0; }
Nota come allochiamo e liberiamo 9 chunk della stessa dimensione in modo che **riempiano il tcache** e l'ottavo è memorizzato nel bin non ordinato perché è **troppo grande per il fastbin** e il nono non è liberato, quindi il nono e l'ottavo **non vengono uniti con il chunk superiore**. Poi allochiamo un chunk più grande di 0x110 che fa **andare il chunk nel bin non ordinato nel small bin**.
Compilalo e debuggalo con un breakpoint nell'operazione `ret` della funzione `main`. Poi con `gef` puoi vedere che il bin tcache è pieno e un chunk è nel small bin:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=15, size=0x110, count=7] ← Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in unsorted bin.
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
[+] small_bins[16]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[+] Found 1 chunks in 1 small non-empty bins.
Grandi bin
A differenza dei piccoli bin, che gestiscono chunk di dimensioni fisse, ogni grande bin gestisce un intervallo di dimensioni dei chunk. Questo è più flessibile, permettendo al sistema di accomodare varie dimensioni senza la necessità di un bin separato per ogni dimensione.
In un allocatore di memoria, i grandi bin iniziano dove finiscono i piccoli bin. Gli intervalli per i grandi bin crescono progressivamente, il che significa che il primo bin potrebbe coprire chunk da 512 a 576 byte, mentre il successivo copre da 576 a 640 byte. Questo schema continua, con il bin più grande che contiene tutti i chunk sopra 1MB.
I grandi bin sono più lenti da operare rispetto ai piccoli bin perché devono ordinare e cercare attraverso un elenco di dimensioni di chunk variabili per trovare la migliore corrispondenza per un'allocazione. Quando un chunk viene inserito in un grande bin, deve essere ordinato, e quando la memoria viene allocata, il sistema deve trovare il chunk giusto. Questo lavoro extra li rende più lenti, ma poiché le allocazioni grandi sono meno comuni di quelle piccole, è un compromesso accettabile.
Ci sono:
32 bin di intervallo 64B (collidono con i piccoli bin)
16 bin di intervallo 512B (collidono con i piccoli bin)
8 bin di intervallo 4096B (parte collidono con i piccoli bin)
4 bin di intervallo 32768B
2 bin di intervallo 262144B
1 bin per le dimensioni rimanenti
Codice delle dimensioni dei grandi bin
```c // From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
</details>
<details>
<summary>Aggiungi un esempio di grande blocco</summary>
```c
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
char *chunks[2];
chunks[0] = malloc(0x1500);
chunks[1] = malloc(0x1500);
free(chunks[0]);
chunks[0] = malloc(0x2000);
return 0;
}
2 grandi allocazioni vengono eseguite, poi una viene liberata (mettendola nel bin non ordinato) e viene effettuata un'allocazione più grande (spostando quella libera dal bin non ordinato al bin grande).
Compilalo e debugga con un breakpoint nell'operazione ret della funzione main. Poi con gef puoi vedere che il bin tcache è pieno e un chunk è nel bin grande:
gef➤heapbin────────────────────────────────────────────────────────────────────────────────Tcachebinsforthread1────────────────────────────────────────────────────────────────────────────────Alltcachebinsareempty─────────────────────────────────────────────────────────────────────────Fastbinsforarenaat0xfffff7f90b00─────────────────────────────────────────────────────────────────────────Fastbins[idx=0,size=0x20]0x00Fastbins[idx=1,size=0x30]0x00Fastbins[idx=2,size=0x40]0x00Fastbins[idx=3,size=0x50]0x00Fastbins[idx=4,size=0x60]0x00Fastbins[idx=5,size=0x70]0x00Fastbins[idx=6,size=0x80]0x00───────────────────────────────────────────────────────────────────────UnsortedBinforarenaat0xfffff7f90b00───────────────────────────────────────────────────────────────────────[+] Found 0 chunks in unsorted bin.────────────────────────────────────────────────────────────────────────SmallBinsforarenaat0xfffff7f90b00────────────────────────────────────────────────────────────────────────[+] Found 0 chunks in 0 small non-empty bins.────────────────────────────────────────────────────────────────────────LargeBinsforarenaat0xfffff7f90b00────────────────────────────────────────────────────────────────────────[+] large_bins[100]: fw=0xaaaaaaac1290, bk=0xaaaaaaac1290→Chunk(addr=0xaaaaaaac12a0, size=0x1510, flags=PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA)[+] Found 1 chunks in 1 large non-empty bins.
Top Chunk
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711/*TopThe top-most available chunk (i.e., the one bordering the end ofavailable memory) is treated specially. It is never included inany bin, is used only if no other chunk is available, and isreleased back to the system if it is very large (seeM_TRIM_THRESHOLD). Because top initiallypoints to its own bin with initial zero size, thus forcingextension on the first malloc request, we avoid having any specialcode in malloc to check whether it even exists yet. But we stillneed to do so when getting memory from system, so we makeinitial_top treat the bin as a legal but unusable chunk during theinterval between initialization and the first call tosysmalloc. (This is somewhat delicate, since it relies onthe 2 preceding words to be zero during this interval as well.)*//* Conveniently, the unsorted bin can be used as dummy top on first call */#defineinitial_top(M) (unsorted_chunks (M))
Fondamentalmente, questo è un chunk che contiene tutta l'heap attualmente disponibile. Quando viene eseguito un malloc, se non c'è alcun chunk libero disponibile da utilizzare, questo top chunk ridurrà la sua dimensione per dare lo spazio necessario.
Il puntatore al Top Chunk è memorizzato nella struct malloc_state.
Inoltre, all'inizio, è possibile utilizzare il chunk non ordinato come top chunk.
Osserva l'esempio del Top Chunk
```c #include #include
int main(void) { char *chunk; chunk = malloc(24); printf("Address of the chunk: %p\n", (void *)chunk); gets(chunk); return 0; }
Dopo aver compilato e debuggato con un punto di interruzione nell'opcode `ret` di `main`, ho visto che il malloc ha restituito l'indirizzo `0xaaaaaaac12a0` e questi sono i chunk:
```bash
gef➤ heap chunks
Chunk(addr=0xaaaaaaac1010, size=0x290, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac1010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................]
Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac12a0 41 41 41 41 41 41 41 00 00 00 00 00 00 00 00 00 AAAAAAA.........]
Chunk(addr=0xaaaaaaac12c0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac12c0 41 64 64 72 65 73 73 20 6f 66 20 74 68 65 20 63 Address of the c]
Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac16d0 41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00 AAAAAAA.........]
Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← top chunk
Dove si può vedere che il chunk superiore si trova all'indirizzo 0xaaaaaaac1ae0. Non è una sorpresa perché l'ultimo chunk allocato era in 0xaaaaaaac12a0 con una dimensione di 0x410 e 0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0.
È anche possibile vedere la lunghezza del Top chunk nell'intestazione del suo chunk:
Quando viene utilizzato malloc e un chunk viene diviso (ad esempio, dall'unsorted bin o dal top chunk), il chunk creato dal resto del chunk diviso è chiamato Ultimo Rimanente e il suo puntatore è memorizzato nella struct malloc_state.
Flusso di Allocazione
Controlla:
Flusso di Liberazione
Controlla:
Controlli di Sicurezza delle Funzioni Heap
Controlla i controlli di sicurezza eseguiti dalle funzioni ampiamente utilizzate nell'heap in:
