Tesi di laurea Strumento per l iniezione di guasti software nel sistema operativo GNU/Linux Anno Accademico 2009/2010 Relatore Ch.mo prof. Marcello Cinque Correlatore Ch.mo ing. Roberto Natella Candidato Davide Fazzone Matr. 534/002977
Obiettivi della tesi Realizzazione di uno strumento automatico per la creazione e l'iniezione di guasti software all'interno del kernel del sistema operativo open-source GNU/Linux Valutazione, attraverso una fase finale di testing, dell influenza di questi guasti indotti sul corretto funzionamento del sistema operativo e su eventuali applicazioni Ciò è di fondamentale importanza in sistemi safetycritical, i cui malfunzionamenti possono provocare danni a persone o all ambiente circostante.
Cos è la Fault Injection Il test di un programma può essere usato per mostrare la presenza di bug, ma mai per mostrare la loro assenza (E. Dijkstra 1970) Esempio di guasto iniettato Definizione: Volontaria iniezione di guasti all'interno del sistema sotto osservazione, per valutarne il comportamento all'insorgere dei guasti iniettati Usata nella validazione della Fault Tolerance Differenze tra Fault, Error e Failure Ciclo Fault-Error-Failure
Metodologie di Fault Injection Tecnica G-SWFIT: Modifiche a livello del codice binario Adatta a componenti OTS Necessità di essere adattata a hardware, sistema operativo e compilatore Fault Injection Tool (FIT) Modifiche a livello del codice sorgente Adatta a software open-source Necessità di poter accedere al codice sorgente Tecnica G-SWFIT Passi del Tool di Fault Injection
La Fault Injection nel Sistema Operativo Perché fare F.I. nel Sistema Operativo? Risulta di interesse osservare come i fallimenti a livello del S.O. si propagano nel software applicativo Il S.O. è realizzato per aggregazione di componenti (problematiche di integrazione) Concentrare i test sui driver Secondo studi statistici, i guasti nei driver sono la principale causa di fallimento dei Sistemi Operativi in quanto scritti da terze parti Failure di un driver in sistema Windows Modi di fallimento possibili: Hang del sistema Crash del sistema Errori Applicativi Come il Sistema Operativo reagisce a questi fallimenti
Uso del tool sul codice del kernel Linux Metodo e componenti usate Virtualizzazione (QEMU) Tool ausiliarii (mcpp, httperf) Realizzazione di un processo per generare dal codice sorgente diverse versioni del driver con guasti iniettati Problemi nell uso del tool sul codice del kernel Linux Necessità di progettare un tool che permetta di usare normalmente il FIT
Processo automatico realizzato Fase iniziale di configurazione ed ottenimento dei sorgenti Utilizzo del fix-tool creato per adattare il codice del kernel, al fine di poter applicare il tool di Fault Injection in uso Rimozione di macro, direttive al precompilatore e parole chiave non aderenti allo standard del linguaggio Compilazione delle patch generate Test per ogni patch
FNM-Linux (Finmeccanica Linux) v. 2.1.1 Basata sulla meta-distribuzione Gentoo Linux Le principali feature di questa distribuzione sono: Management di prodotti industriali Real Time spinto su sistemi multi-core Scalabilità garantita Software Safety D0178B Licensa GPL2 Kernel in uso: Linux-2.6.24-FNM_v2.1 (evoluzione della versione 2.6.24.7 del kernel Linux, opportunamente patchato secondo le loro necessità aziendali). Equipaggiata di Abyss Web Server per il test delle schede di rete Le tre schede di rete sotto test: Caso di Studio Realtek NE2000 (modulo ne2k-pci LOC: 716) Realtek RTL-8139C (modulo rtl8139cp LOC: 2101) Adv. Micro-Devices PCnet32 (modulo pcnet32 LOC: 3106)
Risultati del Caso di Studio Per ogni scheda sono state create diverse centinaia di patch Si escludono: quelle che non permettevano una corretta compilazione quelle che non riguardavano il modulo in esame ma qualche libreria inclusa Dalla compilazione delle rimanenti si ricavano i moduli buggati Ognuno di questi viene messo in esercizio e testato tramite uno script di workload Si ottengono, quindi, i risultati statistici desiderati
Conclusioni e Sviluppi Futuri Statistiche complessive 73,6% dei casi di test senza errori 11,8% dei casi di test con Crash 2,5% dei casi di test con Hang 12,1% dei casi di test con Errori Applicativi Percentuali dei failure riscontrati rispetto al totale degli errori Sviluppi Futuri Logging in caso di Hang Modalità diverse da test a scatola chiusa
Grazie dell attenzione