Un approccio innovativo alla tecnica di robustness testing del sistema operativo Linux

Transcript

1 tesi di laurea Un approccio innovativo alla tecnica di robustness testing del sistema Anno Accademico 2009/2010 relatore Ch.mo prof. Domenico Cotroneo correlatori Ing. Domenico Di Leo Ing. Roberto Natella candidato Mariana Esposito Matr. 885/390 1

2 Contesto Verifica dei Sistemi mission critical Test di robustezza Obiettivi Migliorare l efficienza l e l efficacia l del robustness testing Applicato ad un caso di studio reale: FINMECCANICA LINUX 2

3 Robustezza Capacità di un sistema di funzionare correttamente in presenza di input eccezionali o carico di lavoro eccessivo. [IEEE Std ] Robustness Testing Struttura: Workload: : Input validi per il sistema Faultload: : Input eccezionali o input che creano condizioni di stress Limite: Individuare lo spazio dei valori di input 3

4 Stato dell arte : error model TIPOLOGIA BIT FLIP RANDOM (FUZZY) TIPO DI DATO DESCRIZIONE Inversione di un bit Sostituzione con valore casuale Sostituzione con valore predefinito ESEMPIO read (8, 0x , 4096) read (8, 0x , 4096) read (8, 0x , 4096) read (8, 0x12ff8678, 4096) read (8, 0x , 4096) read (8, 0x , 4096) 4

5 Nei sistemi operativi? Punti Iniezione: System call Interfaccia driver Interfaccia Applicazioni Interfaccia Driver Applicazioni Sistema operativo Possibili fallimenti: Crash del sistema Stallo Corruzione di memoria D1 D2 D3 D4 Hardware 5

6 Test di robustezza: tool e limiti Alcuni tool esistenti Input random: Scrashme Input basati su tipi di dato: Ballista Limiti attuali Difficoltà a rilevare vulnerabilità gravi Test non considerano lo stato delle risorse (memoria, messaggi, file ) ) del sistema. 6

7 Approccio proposto Considerare gli input non validi per le system call tenendo in considerazione lo stato delle risorse (memoria, messaggi, file, socket ) del sistema, sollecitato da workload esistenti. I1 I5 I9 7

8 Classi di fallimento Classi di fallimento Classe 1: non si osservano fallimenti Classe 2: fallimento applicazione Classe 3: fallimento sistema operativo Strategie di rilevazione di fallimenti Rilevazione di stallo attraverso task canarino Asserzioni nel codice Check stack overflow Check sui limitidelleareedimemoriaallocate dal kernel 8

9 Caso di studio FNM Linux (Finmeccanica Linux) v Basata sulla meta distribuzione Gentoo Linux Management di prodotti industriali Real Time su sistemi multi core Scalabilità Software Safety D0178B Kernel: Linux FNM_v2.1 (evoluzione della versione , applicate patch secondo le necessità aziendali). 9

10 Configurazione Test Workload Database MySql I/O Disco Memoria Web server Apache Risorse di rete Middleware DDS RTI IPC System call mmap () Memoria open () File System execve () Processi socket () Rete bind () Rete 10

11 Test preliminari Scrashme: assenza fallimenti del sistema operativo Ballista: fallimento dei processi, ma non del SO Test approccio proposto 33 Input random Iniezioni effettuate per tutti i parametri delle 5 system call in ordine sequenziale Test totali per tipologia: 660 Test non iterativo Unico punto di iniezione 33 input random alla stessa iterazione Test iterativo 11 punti di iniezione 3 valori per ogni iterazione 11

12 Risultati Test Test non iterativo Fallimenti: Solo Classe 1 e Classe 2 Test iterativo Un fallimento di Classe 3 (Crash), i restanti di classe 1 e 2 Primitiva bind() Parametro addrlen Valore iniettato:

13 Conclusione Tecniche di test attuali non considerano lo stato Verifica della rilevanza dello stato del sistema operativo nel test di robustezza Dai test effettuati il sistema operativo Finmeccanica Linux è risultato robusto Sviluppi futuri Ampliare lo spazio degli esperimenti (variare la tipologia di input, aumentare lo spazio di input) Costruire workload ad hoc che sollecitino le risorse Tool che monitori le risorse ed esegua i test 13