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.
Davide Fazzone – Matr. 534/002977
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)
Definizione: Volontaria iniezione di guasti
all'interno del sistema sotto osservazione, per
valutarne il comportamento all'insorgere dei
guasti iniettati
Esempio di guasto iniettato
Usata nella validazione della Fault Tolerance
Differenze tra Fault, Error e Failure
Ciclo Fault-Error-Failure
Davide Fazzone – Matr. 534/002977
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
Davide Fazzone – Matr. 534/002977
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
Davide Fazzone – Matr. 534/002977
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
Davide Fazzone – Matr. 534/002977
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
Davide Fazzone – Matr. 534/002977
Caso di Studio
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:
Realtek NE2000 (modulo “ne2k-pci” – LOC: 716)
Realtek RTL-8139C (modulo “rtl8139cp” – LOC: 2101)
Adv. Micro-Devices PCnet32 (modulo “pcnet32” – LOC: 3106)
Davide Fazzone – Matr. 534/002977
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
Davide Fazzone – Matr. 534/002977
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”
Davide Fazzone – Matr. 534/002977
Grazie dell’attenzione
Davide Fazzone – Matr. 534/002977
