;ftrace è un tracciante interno progettato per aiutare gli sviluppatori e progettisti di sistemi a scoprire cosa sta succedendo all'interno del kernel. Può essere utilizzato per il debug o l'analisi di latenze e problemi di prestazioni che si verificano al di fuori dello spazio utente.


;a causa del modo in cui funziona la macro, questa riga deve comparire prima del blocco #include che altrimenti si troverebbe all'inizio del file. Definire pr_fmt() in questo modo (#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt) fa sì che tutte le stringhe stampate dal file abbiano il nome del modulo preceduto; molti sottosistemi usano una stringa letterale invece del nome del modulo (come nel nostro caso), ma l'intento è lo stesso.


;inclusione necessaria per la libreria ftrace; una delle caratteristiche di ftrace è che ci consente di fare attach di una callback in una parte del kernel. Nello specifico, possiamo dire a ftrace di intervenire ogni volta che il registro rip contiene un certo indirizzo di memoria. Se impostiamo questo indirizzo a quello di sys_chdir (o qualsiasi altra funzione), allora possiamo fare in modo che venga eseguita un'altra funzione.


;definisco *envv[] e *argv[] da passare a call_usermodehelper per chiamare un eseguibile nello userspace;

;le variabili statiche hanno la proprietà di preservare il loro valore anche dopo che sono fuori dal loro ambito. Pertanto, le variabili statiche conservano il valore precedente del loro ambito precedente e non vengono inizializzate nuovamente nel nuovo ambito.

;una funzione statica in C è una funzione che ha un ambito limitato al suo file oggetto. Ciò significa che la funzione statica è visibile solo nel suo file oggetto. Una funzione può essere dichiarata come funzione statica inserendo la parola chiave static prima del nome della funzione.

;struct pt_regs è la struttura che contiene tutti i registri di sistema

;le variabili possono essere dichiarate come costanti utilizzando la parola chiave "const" prima del tipo di dati della variabile. Le variabili costanti possono essere inizializzate una sola volta. Il valore predefinito delle variabili costanti è zero.


;orig_chdir è un puntatore a una funzione e presumibilmente verrà fatto puntare alla syscall originale del chdir.


;questa è la nuova chdir, che prima di ripassare il controllo alla chdir originale stampa info a livello kernel e prima chiama la call_usermodehelper per fare la cat del /etc/password nel file /tmp/list; call_usermodehelper : prepara e avvia un'applicazione in modalità utente

;il tag asmlinkage dovrebbe dire al compilatore che i parametri della funzione saranno passati attraverso lo stack; tuttavia c'è un'importante precisazione da fare: anche senza alcun __attribute__ speciale per forzare il compilatore a usare lo stack per i parametri, le chiamate di sistema nelle recenti versioni del kernel prendono ancora i parametri dallo stack indirettamente attraverso un puntatore a una struttura pt_regs (che contiene tutti i registri dello userspace salvati nello stack). Ciò si ottiene attraverso un set di macro moderatamente complesso (SYSCALL_DEFINEx) che fa tutto in modo trasparente.


;a seconda della versione del kernel viene ritornato un unsigned long (un indirizzo), o utilizzando la classica kallsyms_lookup_name (restituisce l'indirizzo associato a qualsiasi simbolo nella tabella dei simboli del kernel) o attraverso le funzioni register_kprobe e unregister_kprobe.

;kprobes ti consente di entrare dinamicamente in qualsiasi routine del kernel e raccogliere informazioni di debug e prestazioni senza interruzioni. register_kprobe = imposta un breakpoint all'indirizzo kp->addr. Quando viene raggiunto il punto di interruzione, kprobes chiama kp->pre_handler. Dopo che l'istruzione è stata analizzata e dopo un singolo step, kprobe chiama kp->post_handler. Quindi qui stiamo cercando l'indirizzo della funzione il cui simbolo è const char *name.


;definisce delle costanti in caso di versioni kernel inferiori alla 5.11


;in linux, la parola chiave "__always_inline" forza l'inline di una funzione e "noinline" impedisce l'inline di una funzione. Non usiamo la parola chiave "inline" perché non funziona.


;il campo .original nella struttura ftrace_hook viene impostato sull'indirizzo di memoria della chiamata di sistema denominata in .name (hook->name).


;otteniamo l'indirizzo della struct ftrace_hook per la nostra funzione usando una macro container_of() e l'indirizzo della struttura ftrace_ops incorporato nella struttura ftrace_hook. Successivamente, sostituiamo il valore del registro rip nella struttura pt_regs con l'indirizzo della nostra callback. Per architetture diverse da x86_64, questo registro può avere un nome diverso (come pc o ip). L'idea di base, tuttavia, è la stessa.

;si noti l'identificatore notrace. Questo identificatore può essere utilizzato per contrassegnare le funzioni vietate per il trace del kernel linux con ftrace. Usando questo specificatore, puoi evitare che il sistema si blocchi se chiama accidentalmente una di queste funzioni dalla tua chiamata ftrace che è attualmente tracciata da ftrace.

;la chiamata ftrace viene solitamente chiamata con una prelazione disabilitata (proprio come kprobes), anche se potrebbero esserci alcune eccezioni. Ma nel nostro caso, questa limitazione non è così importante poiché dobbiamo sostituire solo otto byte del valore rip nella struttura pt_regs.

;poiché la funzione wrapper e l'originale vengono eseguite nello stesso contesto, entrambe le funzioni hanno le stesse restrizioni. Cosa diversa se si vuole creare un hook per un gestore di interrupt.

;guardando questa funzione (fh_ftrace_thunk), vediamo che tutto ciò che sta realmente facendo è impostare il registro rip in modo che punti alla funzione hook. Tutto ciò che rimane è assicurarsi che questa chiamata venga eseguita ogni volta che rip contiene l'indirizzo di sys_chdir (che è la nostra syscall del kernel); e questa cosa viene fatta da ftrace_set_filter_ip() e register_ftrace_function() nella funzione fh_install_hooks().


;ftrace_set_filter_ip() dice a ftrace di eseguire la nostra chiamata solo quando rip è l'indirizzo di sys_chdir (che era già stato salvato in hook->address precedentemente). Infine, mettiamo in moto il tutto chiamando register_ftrace_function(). A questo punto, l'hook è pronto. Come si può immaginare, quando rimuoviamo il modulo, viene chiamato fh_exit(), fh_remove_hooks() fa tutto questo al contrario.

;rip probabilmente verrà modificato, quindi dobbiamo avvisare ftrace di ciò impostando FTRACE_OPS_FL_IP_MODIFY. Per impostare questo flag, dobbiamo anche impostare il flag FTRACE_OPS_FL_SAVE_REGS per poter passare la struttura pt_regs della syscall originale insieme al nostro hook. Infine, dobbiamo anche disattivare la protezione dalla ricorsione incorporata in ftrace, che è la ragione del flag FTRACE_OPS_FL_RECURSION_SAFE (per impostazione predefinita questo flag è attivo, quindi ripristinarlo lo disattiva).

;la prima cosa che accade è chiamare fh_resolve_hook_address() sull'oggetto ftrace_hook. Questa funzione usa semplicemente kallsyms_lookup_name() (fornito da <linux/kallsyms.h>, attraverso la funzione lookup_name che utilizza kprobes in caso di versioni del kernel superiori) per trovare l'indirizzo in memoria della vera syscall, cioè sys_chdir nel nostro caso. Questo è importante perché dobbiamo salvarlo sia in modo da poterlo assegnare a orig_chdir() sia per poter ripristinare tutto il contesto originale quando il modulo viene rimosso dalla memoria. Salviamo questo indirizzo nel campo .address della struttura ftrace_hook.

;To trace just a specific function in this case, ftrace_set_filter_ip() can be used
;To enable tracing call:
;register_ftrace_function(&ops);
;To disable tracing call:
;unregister_ftrace_function(&ops);


;una volta configurato l'array (demo_hooks[]), usiamo fh_install_hooks() per installare le funzioni hooks e fh_remove_hooks() per rimuoverle. Tutto quello che dobbiamo fare è inserirle rispettivamente nelle funzioni fh_init e fh_exit ed eseguire un piccolo controllo degli errori. fh_install_hooks() e fh_remove_hooks scorrono semplicemente l'array demo_hooks[] e chiamano fh_install_hook() e fh_remove_hook() su ciascun elemento.


;per rendere il riempimento della struttura ftrace_hook un po' più rapido e semplice, abbiamo la macro HOOK; La macro SYSCALL_NAME si occupa del fatto che, nei kernel a 64 bit, le chiamate di sistema hanno __x64_ anteposto ai loro nomi.


;la macro HOOK richiede il nome della chiamata di sistema o della funzione del kernel che stiamo prendendo di mira (nel nostro caso sys_chdir), la funzione hook che abbiamo scritto (hook_chdir) e l'indirizzo di dove vogliamo salvare la chiamata di sistema originale (orig_chdir). Si noti che demo_hooks[] può contenere più di un semplice hook di funzione per rootkit più complicati, che hanno più funzionalità.




Edited by Dr. Pepper - 3/12/2023, 14:00