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

Recommendations

Info

56 4. L’implementazione 4.3 Implementazione del sistema I punti chiave dell’implementazione non sono molti e di seguito verranno descritti. Uno di essi è lo script per la collezione dei dati, l’altro è l’implementazione della funzione NewArgs(). 4.3.1 Lo script di data collection In base a quanto specificato nello script verranno raccolti più o meno dati che verranno processati dal modello. I dati raccolti sono in ogni caso lo stack del processo al momento della system call e il suo nome. Eventualmente vengono raccolti anche uno o più parametri e il valore di ritorno. Lo script inizia con: string pname; BEGIN { pname = "gpserver"; } In questa parte viene inizializzata la variabile pname che consente di specificare il nome del processo da monitorare. Successivamente vengono inizializzate alcune variabili che conterranno i valori collezionati. syscall:::entry /execname == pname/ { self->arg0 = 0; self->arg1 = 0; self->arg2 = 0; self->arg3 = 0; self->arg4 = 0; self->arg5 = 0; } Si noti l’uso di self, necessario a memorizzare il valore localmente rispetto al thread. Le variabili inizializzate conterranno fino a 5 parametri delle system call. In questa definizione si può notare anche l’espressione /execname == pname/, che fa attivare la sonda solo se il nome del processo è quello specificato. Infine prendiamo in esame la parte che effettivamente raccoglie i dati.
4.3. Implementazione del sistema 57 syscall::accept:entry /execname == pname/ { self->arg0 = arg0; } syscall::accept:return /execname == pname/ { @accept[probefunc, arg0, self->arg0, ustack()] = max(timestamp); } L’esempio è relativo alla chiamata di sistema accept(). Nella sonda entry i valori dei parametri sono disponibili nelle variabili arg0, ..., argN. Nella sonda return invece in arg0 e in arg1 è disponibile il valore di ritorno. Quando la sonda entry viene attivata il primo parametro di accept() (un file descriptor restituito prece- dentemente molto probabilmente da socket()) viene semplicemente salvato nella variabile self->arg0. Quando viene attivata la sonda return invece viene costruito l’aggregato con: • Nome della system call • Valore di ritorno • Primo parametro, salvato dalla entry • Stack corrente del processo L’aggregato così composto viene messo in un buffer in user space a disposizione del consumer che, nel nostro caso, è l’implementazione del modello proposto. 4.3.2 Implementazione di NewArgs() Nell’implementazione della fase di training del sistema è particolarmente importante avere una struttura dati che permetta a NewArgs() di restituire velocemente il suo risultato. Ricordiamo che data una traccia T formata dagli eventi e1, . . . , en, possi- bilmente ripetuti, e dato un evento ek la funzione NewArgs() deve restituire tutti gli eventi apparsi tra ek e la sua occorrenza immediatamente precedente, esclusi quelli che appaiono anche prima di essa. Nell’esempio di Figura 4.7 gli eventi registrati sono: (A = 1); (B = 1); (C = 1); (B = 2); (C = 2); (A = 3); (D = 1)
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 and 64: 4.2. Introduzione a DTrace 53 un ce
Page 65: 4.2. Introduzione a DTrace 55 1 sta
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?