Generazione del grafo di chiamate statiche per il kernel Linux

Question

Sto cercando uno strumento per generare staticamente un grafo di chiamata del kernel Linux (per una configurazione kernel specifica). Il grafo delle chiamate generato dovrebbe essere "completo", nel senso che tutte le chiamate sono incluse, comprese quelle indirette potenziali che si possono assumere solo attraverso l'uso di puntatori di funzione nel caso del kernel di Linux.

Ad esempio, questo può essere fatto analizzando i tipi di puntatore della funzione: questo approccio porterebbe a bordi superflui nel grafico, ma per me va bene.

ncc sembra implementare questa idea, tuttavia non sono riuscito a farlo funzionare sul kernel 3.0. Qualche altro suggerimento?

Suppongo che questo approccio potrebbe anche portare a bordi mancanti nei casi in cui vengono utilizzati i cast di puntatori di funzione, quindi sarei anche interessato a sapere se questo è probabile nel kernel di Linux.

Come nota a margine, sembra che ci siano altri strumenti che sono in grado di fare un'analisi semantica dell'origine per inferire potenziali valori del puntatore, ma AFAICT, nessuno di essi è progettato per essere utilizzato in un progetto come il kernel di Linux .

Qualsiasi aiuto sarebbe molto apprezzato.

Answer 1

Abbiamo eseguito l'analisi globale dei punti (con puntatori di funzione indiretti) e la costruzione completa del grafico di chiamata di sistemi C monolitici di 26 milioni di righe (18.000 unità di compilazione).

Lo abbiamo fatto utilizzando il nostro DMS Software Reengineering Toolkit, il suo C Front End e il suo associated flow analysis machinery. Il meccanismo di analisi dei punti (e le altre analisi) sono conservativi; sì, ottieni alcuni punti fasulli e, di conseguenza, i bordi delle chiamate. Questi sono abbastanza difficili da evitare. È possibile aiutare tali analizzatori fornendo alcuni fatti cruciali sulle funzioni chiave e sfruttando le conoscenze come "sistemi embedded [e sistemi operativi] tendono a non avere cicli nel grafico delle chiamate", il che significa che è possibile eliminare alcuni di questi. Certo, devi consentire eccezioni; la mia morale: "nei grandi sistemi, tutto accade".

Il problema particolare includeva i moduli C (!) Caricati dinamicamente utilizzando uno schema di caricamento speciale specifico per questo particolare software, ma che si aggiungeva al problema.

I cast sui puntatori di funzione non devono perdere i bordi; un'analisi conservativa dovrebbe semplicemente assumere che il puntatore del cast corrisponda a qualsiasi funzione nel sistema con la firma corrispondente al risultato castato. Più problematici sono i cast che producono firme di sorta compatibili; se lanci un puntatore a funzione void * foo (uint) quando la funzione effettiva chiamata accetta un int, i punti di analisi sceglieranno necessariamente le funzioni sbagliate in modo conservativo. Non puoi incolpare l'analizzatore per questo; il cast si trova in quel caso. Sì, abbiamo visto questo tipo di spazzatura nel sistema a 26 milioni di linee.

Questa è sicuramente la scala giusta per l'analisi di Linux (che credo sia solo di 8 milioni di righe :-). Ma non l'abbiamo provato in particolare su Linux.

La configurazione di questo strumento è complicata perché è necessario acquisire tutti i dettagli relativi alle compilazioni stesse e in particolare la configurazione del kernel di Linux che si desidera generare. Quindi devi praticamente intercettare le chiamate del compilatore per ottenere gli switch della riga di comando, ecc.