Un modello integrato control-flow e data-flow per il rilevamento ...

Recommendations

Info

54 4. L’implementazione L’aggregato poi verrà copiato in un buffer in user space, che potrà essere letto ed elaborato dai consumer. La sintassi per specificare un aggregato è @[record1, record2, . . .] e, nel nostro caso, è stato inserito il nome della chiamata di sistema (probefunc) e lo stack (ustack()). Procedendo in questo modo DTrace, ad ogni ingresso nella chiamata di sistema, costruisce una struttura dati apposita (Figura 4.5) alla quale si può accedere da un consumer scritto in C. L’intero aggregato è rappresentato da una struttura denominata dtrace aggdata la quale contiene un array (dtrace aggdesc) che punta ai vari record. Ogni record ha un particolare tipo di dati, nel nostro caso probefunc è un char * mentre ustack() è un array di uint64 t. dtrace_aggdata dtada_desc dtada_data dtada_percpu[0] dtada_percpu[1] dtrace_aggdesc dtagd_rec[1] dtagd_rec[2] probename ustack ... dtrace_recdesc dtrd_offset dtrace_recdesc dtrd_offset Figura 4.5: Strutture dati usate da un consumer DTrace. Un consumer ha la funzione di prendere uno script DTrace, compilarlo e passare l’oggetto risultante al framework DTrace. Questi dettagli sono gestiti con poche chiamate alla libreria. Fatto questo, si può entrare in un loop e iniziare a consumare i dati che arrivano dal kernel. All’interno di un loop infinito si chiama inizialmente la funzione dtrace work(), la quale si occupa di collezionare tutti i dati necessari. All’uscita da dtrace work() sono disponibili gli aggregati che sono stati collezionati nell’ultimo ciclo. Questi vengono processati uno ad uno tramite una funzione walk() definita dall’utente che lavora sui singoli record. All’interno di walk(), per accedere ai valori probefunc e
4.2. Introduzione a DTrace 55 1 static int 2 walk(const dtrace_aggdata_t *data, void *arg) 3 { 4 dtrace_aggdesc_t *aggdesc = data->dtada_desc; 5 dtrace_recdesc_t *ustackrec, *datarec, *namerec, *argrec; 6 uint64_t *ustack, *pc, timestamp; 7 char *name; 8 9 /* [...] */ 10 11 /* Nome system call */ 12 namerec = &aggdesc->dtagd_rec[1]; 13 name = data->dtada_data + namerec->dtrd_offset; 14 15 /* Stack */ 16 ustackrec = &aggdesc->dtagd_rec[2]; 17 if (ustackrec->dtrd_action != DTRACEACT_USTACK) 18 fatal("aggregation key is not a ustack\n"); 19 ustack = (uint64_t *)(data->dtada_data + ustackrec->dtrd_offset); 20 21 /* [...] */ 22 } Figura 4.6: Snippet di walk(). ustack(), si procederà come in Figura 4.6. A questo punto è possibile processarli in qualsiasi modo si voglia. 4.2.2 Note riguardo a DTrace I primi esperimenti con i consumer custom sono stati fatti in ambiente Mac OS X, fino a quando non è emerso che, per motivi ancora non del tutto chiari, la funzione ustack() “perdeva per strada” dei frame. Non solo, i frame persi non erano gli stessi su piattaforma Intel e su piattaforma PowerPC. Inizialmente si è sospettato che questo accadesse a causa di ottimizzazioni introdotte dal compilatore (del tipo di -fomit-frame-pointer), ma andando a guardare il codice macchina generato si è visto che non era questo il caso. Si è dunque spostato lo sviluppo su Solaris (OpenIndiana 151a), dove nessun stack frame viene perso. Questo comportamento verrà discusso a breve con gli sviluppatori di DTrace.
Page 1:
Università degli Studi di Udine Fa
Page 5 and 6:
Ringraziamenti In questo percorso m
Page 7 and 8:
Indice 1 Introduzione 1 1.1 Anomaly
Page 9 and 10:
Elenco delle figure 1.1 Codice sema
Page 11 and 12:
1 Introduzione Dai tempi della “d
Page 13 and 14: 1.1. Anomaly detection e system cal
Page 15 and 16: 1.2. Obiettivo del lavoro 5 informa
Page 17 and 18: 1.3. Struttura della tesi 7 seconda
Page 19 and 20: 2 Modelli per l’anomaly detection
Page 21 and 22: 2.1. Modelli control flow 11 con un
Page 23 and 24: 2.1. Modelli control flow 13 • Vi
Page 25 and 26: 2.1. Modelli control flow 15 1 int
Page 27 and 28: 2.2. Modelli data flow 17 • se v
Page 29 and 30: 2.2. Modelli data flow 19 suo scopo
Page 31 and 32: 2.3. Discussione dei modelli studia
Page 33 and 34: 2.3. Discussione dei modelli studia
Page 35 and 36: 3 Un modello che integra control fl
Page 37 and 38: 3.1. Debolezze dei modelli esistent
Page 45 and 46: 3.2. Proposta 35 1 int main(void) 2
Page 47 and 48: 3.3. Costruzione del modello 37 mai
Page 49 and 50: 3.3. Costruzione del modello 39 Un
Page 51 and 52: 3.3. Costruzione del modello 41 Tra
Page 53 and 54: 3.3. Costruzione del modello 43 Par
Page 55 and 56: 3.3. Costruzione del modello 45 Tut
Page 57 and 58: 3.5. L’algoritmo per la verifica
Page 59 and 60: 3.5. L’algoritmo per la verifica
Page 61 and 62: 4 L’implementazione L’implement
Page 63: 4.2. Introduzione a DTrace 53 un ce
Page 67 and 68: 4.3. Implementazione del sistema 57
Page 69 and 70: 4.4. Costo computazionale del model
Page 71 and 72: 4.4. Costo computazionale del model
Page 73 and 74: 5 Conclusioni e sviluppi futuri La
Page 75 and 76: 5.2. Sviluppi futuri 65 5.2.1 L’u
Page 77 and 78: 5.2. Sviluppi futuri 67 sistemi. In
Page 79 and 80: Bibliografia [1] System V Applicati
show all

Un modello integrato control-flow e data-flow per il rilevamento ...

Create successful ePaper yourself

Delete template?

Save as template?