Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea magistrale Un infrastruttura di robustness testing per sistemi virtualizzati in ambiente Xen Anno Accademico relatori Ch.mo prof. Marcello Cinque Ch.mo Ing. Roberto Natella Candidato Camillo D Avino matr. M63/76

2 Alla mia famiglia

3 Indice Abstract 5 Introduzione 8 Capitolo 1. Fault injection e robustness testing Affidabilità dei sistemi software Minacce e approcci all affidabilità Fault injection Tipi di fault injection Mutazione del codice Robustness testing Scopo della tesi Struttura della tesi 26 Capitolo 2. Infrastrutture di virtualizzazione Che cos è la virtualizzazione? Perché virtualizzare? Macchina virtuale Cenni storici Alcuni esempi di virtualizzazione Tipi di virtualizzazione Xen hypervisor Architettura Configurazioni Xen e i meccanismi di protezione dell architettura IA Gestione della memoria Analogie con i sistemi operativi Approfondimento sulle hypercall 56 Capitolo 3. Tool di fault injetcion Scenario di riferimento Architettura Profiling Scelta dei fault Raccolta dei risultati 73 III

4 3.6 Dettagli implementativi Modifiche al codice sorgente Modulo per l iniezione di guasti Iniettore DomU 84 Capitolo 4. Sperimentazioni Profiling Iniezione dei guasti Scelta delle hypercall Raccolta dei risultati Risultati esperimento Risultati esperimento Bibliografia 116 IV

5 Abstract This paper aims to introduce a new approach to evaluate system reliability in virtualized environments. The reference scenario includes a Xen hypervisor on which resides several virtual machines, each equipped with a Unix like Operating System. In particular, this work is intended to produce three results: a fault injection tool in virtualized environments, an experiment to evaluate reliability degree exhibited by a single system installed in the context just mentioned and another experiment aimed to assess the obtainable isolation level in virtualized environments. These two tests are made possible by the tools introduced in the previous period. The reasons of this work are based on a wide band of case studies in the literature, where bugs in software systems have been, in extreme cases, even fatal to humans. The main reason is that computer systems have found a place in any context, critical and not. This condition stimulates the research to produce the most effective solutions that increase system reliability. As mentioned before, unlike many approaches in the literature, the novelty introduced by this, involves 5

6 fault injection in the software layer that provides the sharing of resources between virtual machines, and not in the single virtual machine. Therefore, we don t want only test a single machine behavior but we want to extend the analysis to other virtual machines without neglecting the entity that holds them together: the hypervisor. The second experiment also wants to lead a performance analysis. The approach we have used for both tests is based on an existing method in the literature: Ballista. This mechanism allows us to assess the robustness of a system without knowing any implementation details. Indeed, the module considered in the tests is represented by a generic function, to which, applied input values are valid and not, in order to assess module reaction with inputs not necessarily lawful. This paper consists of four chapters. The first chapter contains a discussion about the state of the art about system reliability theory, emphasizing some possible approaches. In particular, we will discuss the method on which is based the tool: Ballista. Finally, we report a brief description of the test scenario, so that the reader has an overview of what will be shown in later chapters. The second chapter consists of a broad discussion about the virtualization theory, deepening the issues of operating system virtualization. Next, we proceed with the illustration of Xen, the hypervisor considered in the tests, indicating the interfacing mechanism with the various virtual machines: the hypercall. 6

7 The third chapter talks about the fault injection tool starting from its architecture. Next, we will explain the implementations of every modules which it is based on. The last chapter, examine, more closely, the two tests that have been mentioned, showing the steps needed to implement each. Finally, after each test, we will carry out the final observations. 7

8 Introduzione Il presente lavoro si pone l obiettivo di introdurre un nuovo approccio per valutare l affidabilità di sistemi in ambienti virtualizzati. Lo scenario di riferimento prevede un hypervisor Xen su cui poggeranno diverse macchine virtuali, ciascuna equipaggiata con un sistema operativo Unix like. In particolare, tale lavoro ha lo scopo di produrre tre risultati: un tool per l iniezione di guasti in ambienti virtualizzati, una sperimentazione mirata a valutare il grado di affidabilità di un singolo sistema installato nel contesto appena accennato, una seconda sperimentazione volta a valutare il livello di isolamento ottenibile in ambienti virtualizzati. I due test sono resi possibili dal tool introdotto all inizio di questa sezione. Le motivazioni alla base di questo lavoro si basano su un ampia forbice di casistiche presenti in letteratura, dove, la presenza di bug nei sistemi software, si è rivelata, in casi estremi, addirittura fatale per l uomo. Ciò è dovuto al fatto che i sistemi informatici hanno trovato spazio in qualsiasi contesto, critico e non. Questa condizione stimola il mondo della ricerca a produrre soluzioni sempre più 8

9 efficaci che incrementino l affidabilità dei sistemi. Come accennato in precedenza, a differenza dei numerosi approcci in letteratura, la novità introdotta dal presente lavoro consiste nell applicazione di guasti nello strato software che garantisce la condivisione delle risorse (CPU, memoria, ) tra macchine virtuali, e non nella singola macchina virtuale. Non si vuole, quindi, conoscere il comportamento solo della singola macchina testata ma si vuole estendere l analisi anche alle altre macchine virtuali senza trascurare l entità che le tiene assieme: l hypervisor. La seconda sperimentazione delle due proposte, ha appunto questa finalità alla quale si aggiunge l intento di eseguire anche un analisi prestazionale. L approccio utilizzato per la conduzione di entrambi i test si basa su un metodo esistente in letteratura: Ballista. Tale meccanismo permette di valutare la robustezza di un sistema senza conoscerne i dettagli implementativi. Infatti, il modulo considerato nei test è rappresentato da una generica funzione (nel nostro caso si parlerà di hypercall), a cui sono applicati valori in ingresso validi e non, allo scopo di valutare le reazioni del modulo in corrispondenza di input non necessariamente leciti. Il presente lavoro si compone di quattro capitoli. Nel primo capitolo si riporta una trattazione circa lo stato dell arte riguardo la teoria dell affidabilità dei sistemi enfatizzando alcuni approcci possibili, presenti in letteratura. In particolare, si dedicherà ampio spazio al metodo su cui si basa il tool: Ballista. Infine, è riportata una breve descrizione dello scenario di riferimento dei test, in modo che il lettore abbia, sin da subito, una visione d insieme di ciò che sarà, dettagliatamente, esposto nei capitoli successivi. 9

10 Il capitolo secondo prevede un ampia trattazione riguardo la teoria della virtualizzazione, approfondendo uno degli argomenti attualmente più considerati: la virtualizzazione dei sistemi operativi. A seguire, si procede con l illustrazione di Xen, l hypervisor considerato nei test, mostrando i meccanismi d interfacciamento con le varie macchine virtuali: le hypercall. Nel terzo capitolo ci si occupa di descrivere le caratteristiche del tool utilizzato nei test, fornendo i dettagli implementativi di ciascun modulo che ne fa parte. L ultimo capitolo, esaminerà, più da vicino, i due test di cui si è accennato, mostrando i passi necessari alla realizzazione di ciascuno. Infine, a valle di ciascun test, sulla base dei risultati ottenuti, si faranno delle considerazioni conclusive. 10

11 Capitolo 1 Fault Injection e Robustness Testing Attualmente l'uomo è circondato da sistemi che, per erogare un certo servizio, ricorrono all'utilizzo di computer. Gli scenari che si possono ritrovare nella realtà sono i più disparati e vanno dal campo della medicina a quello dell intrattenimento, dal settore dei trasporti (aerei, treni) a quello economico-finanziario. A questo punto, una domanda sorge spontanea: ci si può realmente fidare di questi sistemi? Purtroppo la risposta non è del tutto affermativa; basti pensare ai numerosi casi riportati in letteratura in cui il comportamento anomalo di un sistema informatico ha portato a conseguenze anche letali per l uomo. Questo motiva il presente lavoro il cui obiettivo è fornire un tool per il testing di sistemi operativi in ambiente virtualizzato. 11

12 1.1 Affidabilità dei sistemi software Come accennato, i sistemi informatici trovano impiego in svariati scenari critici sia sotto l'aspetto economico (business critical), sia in termini di affidabilità e sicurezza (mission critical). Ad esempio, sistemi e-commerce, sistemi di pagamento elettronico, fanno parte della categoria business critical, mentre, sistemi di controllo del traffico ferroviario o sistemi utilizzati in ambito medico rientrano nella categoria mission critical. Come si può intuire dagli esempi, nei sistemi business critical, i danni, per quanto gravi, si limitano a essere di carattere economico, mentre, nei sistemi mission critical gli eventuali danni possono estendersi all'incolumità di persone e cose. Prima di procedere all illustrazione del concetto di dependability è riportata di seguito una definizione generale del concetto di sistema che più volte ricorre nel presente lavoro: qualsiasi entità in grado di interagire con altre entità (fisiche e non) è ascrivibile ad un sistema. Si definisce servizio, invece, il comportamento del sistema percepito dall utente. Un servizio è corretto se è conforme alle specifiche. Qualora il servizio fornito non sia corretto, si parla di failure. Il concetto di affidabilità dei sistemi informatici fu introdotto per la prima volta nel 1930 nel contesto del calcolatore di Babbage [1] [2]. In seguito, con la prima generazione di computer elettronici furono sperimentate le prime tecniche volte al miglioramento dell'affidabilità, quali: i codici di controllo degli errori o ancora la diagnostica per individuare componenti guasti [3-5]. Allo stesso tempo, J. Von 12

13 Neumann [6], EF Moore e CE Shannon [7] ed i loro successori svilupparono teorie che prevedono l'introduzione della ridondanza per costruire strutture logiche affidabili a partire da componenti meno affidabili, i cui difetti sono mascherati dalla presenza elementi ridondanti. Da questi esempi si può intuire che l'affidabilità è un argomento molto sentito sin dagli albori dell'informatica proprio perché un malfunzionamento di qualsiasi entità o natura può compromettere un servizio più o meno critico. È di seguito proposta una definizione del concetto di dependability [8]: l'affidabilità di un sistema informatico è la capacità di fornire un servizio conforme alle aspettative. Dello stesso autore si riporta un'altra definizione: l'affidabilità di un sistema consiste nella capacità di evitare i disservizi più frequenti, la cui gravità oltrepassa il limite di accettabilità. La dependability è la proprietà di un sistema di elaborazione che incapsula diversi attributi, quali: affidabilità, sicurezza, manutenibilità, ecc. Si potrebbe definirla informalmente come l abilità di un elaboratore di fornire un servizio di cui ci si può fidare in maniera giustificata. Il servizio fornito da un sistema coincide con il suo comportamento così com è percepito dall utente (non necessariamente umano) attraverso un interfaccia, mentre la funzione di un sistema rappresenta ciò che esso è deputato a fare, secondo le relative specifiche funzionali. Perciò, il servizio messo a disposizione sarà corretto quando esso è conforme alle specifiche, altrimenti vorrà dire che si è verificato un malfunzionamento. In situazioni diverse, i vari attributi della dependability assumeranno importanze differenti, ma l efficacia dell approccio risiede proprio nell esaustività e nell integrazione dei diversi concetti legati in qualche modo al problema dell affidabilità. La dependability è una proprietà 13

14 di un sistema di elaborazione che, se affiancata a tutte le altre (funzionalità, usabilità, prestazioni, costo), lo caratterizza completamente. 1.2 Minacce e approcci all affidabilità L'affidabilità di un sistema è minata da numerose cause che possono portare al fallimento del sistema stesso: tra queste si fa riferimento a guasti hardware, errori di progettazione hardware e/o software o ancora errati interventi di manutenzione. Per guasto, s'intende uno stato improprio dell hardware e/o del software del sistema derivante dal fault di una sua parte, provocato ad esempio da fenomeni d interferenza o da errori di progettazione. Gli errori sono invece una parte dello stato di un sistema che possono indurre lo stesso al fallimento; in questo caso il sistema fornisce un servizio non conforme alle specifiche. L'origine di un errore è un fault: è possibile, tra l'altro, che un fault sia la causa di molteplici errori. Infine, per fallimento s'intende l evento in corrispondenza del quale il sistema cessa di fornire un servizio corretto. Nei sistemi attuali i guasti software sono la principale fonte di errore. Un errore software equivale a un errore nel codice e, benché sia permanente, si può manifestare in modo non deterministico. Per esempio, la sua attivazione può avvenire durante l'esecuzione del programma a seguito di una sequenza d input non prevista a priori. Per questo motivo gli errori software sono i più difficili da individuare. Tra gli approcci più comuni finalizzati all incremento dell affidabilità di un sistema, si annoverano il meccanismo di fault tolerance e la tecnica del robustness testing. Uno degli aspetti che contribuisce significativamente all affidabilità di un sistema è il meccanismo di tolleranza ai guasti previsto dal sistema stesso. Formalmente, si 14

15 tratta della capacità che ha un sistema di erogare un servizio, eventualmente a un livello di qualità ridotto, in presenza di uno o più componenti guasti. Chiaramente, la fault tolerance di un sistema non garantisce l immunità da qualsiasi tipo di guasto, ma solo da quelli per cui è stata garantita, in fase di progetto, una protezione adeguata. Alla base del meccanismo di fault tolerance c è il test di robustezza che misura quant è ragionevole il comportamento di un sistema al verificarsi di una situazione imprevista non contemplata dalle specifiche. Queste situazioni impreviste possono essere di varia natura (dati di input non previsti, fallimenti di componenti software o hardware esterni, etc ). Quello che il test fornisce in output è una serie di indicazioni da seguire in fase di sviluppo mirate all incremento del grado di fault tolerance esibito da sistema. 1.3 Fault injection Per fault injection s intende una tecnica che prevede l inserimento intenzionale di guasti all interno di un sistema allo scopo di studiarne, in seguito, il suo comportamento. Tale tecnica è impiegata per testare i meccanismi di tolleranza ai guasti di sistemi o di singoli componenti. In particolare, quest approccio si pone l obiettivo di dare risposta ai seguenti interrogativi: 1. come reagisce un sistema al presentarsi di un guasto? È in grado di rilevare ogni tipo di fault? 2. Il sistema riesce ad isolare un guasto? Ad esempio, nell ipotesi che il guasto venga iniettato in uno specifico componente, si vuole conoscere lo stato 15

16 dell intero sistema; 3. Qual è lo stato del sistema a seguito di una procedura di recovery resa necessaria dall applicazione del guasto? Figura Fault injection system In figura 1.1 si riporta un possibile scenario applicativo della tecnica di iniezione guasti, in cui si riconosce: 1. il sistema target che si vuole testare; 2. il modulo per l iniezione dei guasti; 3. il workload generator che consente di simulare condizioni reali di funzionamento sulla macchia target; 4. il modulo controllore che si occupa di monitorare lo stato degli altri moduli del sistema; 5. il modulo monitor che supervisiona lo stato della macchina testata; 6. il modulo data collector che si occupa di raccogliere i log generati dal sistema. 16

17 1.4 Tipi di fault injection È possibile operare una prima distinzione tra: 1. tecniche di hardware fault injection, rientrano tra i primi tentativi di introdurre guasti direttamente nei dispositivi hardware; tale approccio è motivato dal fatto che apparati quali CPU, bus, memoria sono tra le principali fonti di guasti; 2. tecniche di fault injection orientate alla valutazione della affidabilità del software: come ampiamente discusso nei precedenti paragrafi i sistemi software sono affetti da bug di cui spesso non si conoscono né la posizione all interno del codice, né le situazioni in cui possono rivelarsi né le conseguenze. Lo scopo di quest approccio è proprio quello di evidenziare i bug software e quindi fornire spunti per una loro correzione. Dopo un primo distinguo è possibile fornire altri dettagli per ciascuna delle due categorie individuate sopra. Per quanto riguarda la categoria di hardware fault injection è possibile operare una distinzione in tre classi: 1. iniezione di guasti mediante modifiche all hardware o attraverso l esposizione dello stesso a fenomeni che possono alternarne il funzionamento (es. interferenze elettromagnetiche); 2. simulazione di guasti ad alto livello servendosi di appositi modelli simulati al computer; 3. emulazione di guasti harware via software (software implemented fault injection - SWIFI). Nell ambito dell iniezione di guasti software si riconoscono due possibili approcci: 1. Generic Software Fault Injection Technique (G-SWFIT) [9] ha come obiettivo l introduzione di errori software nel codice binario. 17

18 2. Ballista, una metodologia per il Robustness testing che consiste nell applicazione di combinazioni di valori validi e non come parametri di funzioni, allo scopo di valutare la robustezza di un sistema Mutazione del codice La presente categoria contempla l approccio G-SWFIT. Questa tecnica nasce come soluzione ai casi in cui non è disponibile il codice sorgente del componente da testare (adatta per i sistemi COTS). Si tratta di una tecnica di iniezione di guasti basata su un set di fault injection operators che riproduce direttamente nel codice eseguibile target la sequenza di istruzioni che emula il guasto software. Questi fault injection operators sono la sintesi di uno studio che ha analizzato più di 500 guasti software reali in diversi programmi. Figura G-SWFIT Si riporta, in figura 1.3, i tipi di guasto più frequenti individuati in [9]. La posizione in cui l iniezione deve essere eseguita è scelta attraverso l analisi del codice 18

19 target resa possibile dal G-SWFIT tool, che consente di identificare la posizione in cui un certo tipo di guasto può, realisticamente, verificarsi. Ad esempio, il tipo di guasto MIFS riportato in figura 1.3 può essere solo iniettato laddove presente un costrutto IF. L analisi del codice target è basata sulla conoscenza di come i costrutti di alto livello sono tradotti nei corrispondenti costrutti di basso livello [10]. Figura Fault injection operators Sulla base di quanto riportato in figura 1.3 è di seguito fornita una breve descrizione di ciascuno tipo di fault individuati in [9] che hanno dato vita ai seguenti fault injeciton operator: 1. OMIFS (Missing IF construct and surrounded Statements) indica l assenza del costrutto IF e dello statement ad esso associato; 2. OMFC (Missing Function Call) rappresenta l omissione di una chiamata a funzione; 19

20 3. OMLAC (Missing AND Expr in expression used ad branch condition) consiste nell omissione di una parte di un espressione logica. Detta espressione deve essere composta da almeno due sotto-espressioni collegate tra loro mediante l operatore AND; 4. OMIA (Missing IF constructs around statements) consiste nell omissione di una condizione IF che racchiude un certo blocco di istruzioni; 5. OMVAE (Missing Variable Assignment using an Expression) individua assegnazioni a variabili tramite risultato di espressioni e ne simula l omissione; 6. OMVAV (Missing Variable Assignment using a Value) consiste nell omissione di assegnazioni a variabili con valori constanti; 7. OMVIV (Missing Variable Initialization using a Value) prevede l omissione dell inizializzazione di variabili locali con valori costanti; 8. OMIEB (Missing IF construct plus statements plus ELSE before Statement) comporta la rimozione del costrutto IF, degli statement e del costrutto ELSE associati; 9. OMLOC (Missing OR sub-expression in Logical expression used in branch Condition) prevede l omissione di una parte dell espressione logica impiegata in un salto condizionato. Detta espressione deve essere composta da almeno due sotto-espressioni collegate tra loro mediante l operatore OR; 10. OMLPA (Missing Localized Part of the Algorithm) ha il compito di simulare l omissione di una parte, piccola e localizzata, dell algoritmo; 11 OWVAV (Wrong Value Assigned to a Variable) prevede un assegnazione ad una varibile con un valore non ammissibile; 20

21 12. OWPFV (Wrong Variable in parameter of Function call); la sua funzione è quella di simulare l utilizzo di una variabile errata come parametro passato ad una funzione; 13 OWAEP (Wrong Arithmetic Expression in Parameter of a functioncall) consente di riprodurre lo scenario in cui viene passata ad una funzione una espressione aritmetica invalida. L approccio Source Code Fault Injection (SCFI) si pone ad un livello di astrazione più alto rispetto a G-SWFIT, prevedendo l introduzione dei guasti direttamente nel codice sorgente. Questa tecnica si concretizza nel tool [11] descritto in figura 1.4. Figura 1.4 Tool SCFI Partendo dal codice sorgente del componente che s intende testare, SCFI produce in una prima battuta, una rappresentazione di tale codice sottoforma di un Abstract Syntax Tree utile all individuazione delle locazioni in cui iniettare il fault. Una volta individuata una potenziale locazione in cui applicare il guasto, servendosi dei fault operators discussi nel precedente paragarafo, il tool modifica la parte di codice interessata in linea con l operatore scelto, producendo in output la patch da 21

22 applicare al codice sorgente che sarà, infine, ricompilato. L indisponibilità del codice sorgente del componente da testare comporta la non applicabilità del metodo SCFI Robustness Testing Come accennato nel paragrafo 1.2 la tecnica del robustness testing si pone l obbiettivo di testare il comportamento di un sistema a fronte di situazioni più o meno usuali. Uno dei possibili approcci consiste nell applicare in input al sistema sequenze di valori ammissibili e non, valutandone, successivamente, il comportamento. Ballista [11] è una tecnica di rubustness testing fondata sull approccio appena illustrato. Si tratta di una metodologia basata, appunto, sull applicazione di combinazioni di valori validi e non come parametri delle system call o più in generale delle funzioni. È una tipologia di testing black box dato che non è richiesta la conoscenza dei dettagli implementativi del modulo che s intende testare. Lo scopo di quest approccio è conoscere il comportamento di un modulo sottoposto a determinati test rappresentati da combinazioni d input validi e non. Un generico caso di test prevede un modulo e una lista di valori di input scelti in maniera opportuna. Una possibile strategia di scelta dei valori di input è esemplificata nella figura

23 Figura Generazione dei casi di test per la funzione write() Nell esempio è mostrato un possibile metodo di scelta degli input. Il modulo in questione è la funzione write (int filedes, const void *buffer, size_t nbytes) che prende tre parametri, nell ordine: il descrittore del file, un buffer di memoria e il numero di byte che si vuole scrivere. Dato che write()prende tre parametri di tre tipi diversi, Ballista sceglie, nel generico test, uno dei possibili valori previsti per ciascun argomento. Le linee guida proposte da Ballista, per la scelta dei valori da fornire in input ad un modulo proseguono con i seguenti suggerimenti: - Impostare un qualsiasi parametro con: o un valore negativo; o il minimo e il massimo valore rappresentabile; - modificare il valore di un puntatore facendo in modo che, dopo l iniezione, punti ad un area di memoria inesistente o ad una zona di memoria al limite di quella ammissibile; 23

24 - nel caso di accesso a file, prevedere l apertura contemplando tutte le possibili combinazioni di permessi; Oltre a fornire numerosi spunti su come strutturare una campagna di fault injection, Ballista offre diversi suggerimenti per la fase di raccolta dei risultati. A valle di ciascun test, è prevista la seguente classificazione dei risultati: 1. Catastrophic. I fallimenti di questo tipo si verificano quando il sistema testato si corrompe o la macchina va in crash riavviandosi successivamente; 2. Restart. Questo tipo di fallimento si manifesta quando il modulo testato non riesce a restituire il controllo al chiamante. Tale stato è definito in gergo hung e la sua risoluzione è affidata nella maggior parte dei casi all intervento manuale dell utente che si occuperà del riavvio del modulo in questione; 3. Abort. Un abort si verifica quando il processo corrispondente al modulo testato termina in modo anomalo; 4. Silent. Si tratta di un tipo di fallimento che il sistema non è in grado di rilevare; 5. Hindering. Si tratta di situazioni in cui il modulo richiamato restituisce un codice di errore di cui non è nota la procedura di recovery prevista. 1.5 Scopo della tesi Lo scopo di questo lavoro è fornire strumenti per misurare l affidabilità di un infrastruttura basata su virtualizzazione, in cui più macchine virtuali coesistono. In questo contesto, è fondamentale garantire la disponibilità delle macchine virtuali, e impedire che i malfunzionamenti di una macchina virtuale compromettano l intera infrastruttura. L approccio proposto in questa tesi permette di valutare la robustezza 24

25 dell infrastruttura e il grado d isolamento tra macchine virtuali in presenza di una macchina virtuale guasta. L infrastruttura considerata è costituita dall hypervisor Xen, i cui dettagli saranno esposti nel capitolo successivo. Figura 1.6 Scenario di riferimento per la conduzione dei test Il tool di fault injection presentato in questo lavoro prevede l emulazione degli effetti dei guasti hardware e/o software, applicati a un contesto virtualizzato, mediante modifiche ai codici sorgente delle funzioni che si vuole testare. Sulla base del modello introdotto da Ballista, il tool prevede l alterazione dei valori assunti dai parametri delle funzioni secondo le specifiche dettate dall utente. A tal proposito le modifiche del codice di cui si è parlato in precedenza sono necessarie per poter stabilire a run-time il tipo di alterazione da applicare e il parametro interessato. 25

26 Nella fattispecie data una generica funzione function(type_1 arg_1,..., type_n arg_n), ad ogni sua invocazione, il tool effettua la corruzione di uno dei parametri secondo uno dei possibili tipi di guasto previsti (es., corruzioni random di bit). Con riferimento alla figura 1.6, le funzioni target del tool fanno parte dello strato software, che in ambiente virtualizzato, permettono di interfacciare il sistema operativo con l hardware sottostante. Tali funzioni sono denominate hypercall. Il tool, inoltre, permette di individuare il grado di isolamento messo in atto dall hypervisor: con riferimento alla figura 1.6, si vuole verificare se la corruzione di uno di questi sistemi (A) incide sul funzionamento e sulle prestazioni degli altri (B). 1.6 Struttura della tesi Nei capitoli successivi si discuteranno più approfonditamente dei fondamenti teorici della virtualizzazione (capitolo 2) ponendo particolare enfasi all hypervisor che sarà utilizzato nei test (capitolo 3). Successivamente, si propone una descrizione dettagliata del funzionamento del tool e della sua implementazione (capitolo 4). Infine, è proposto un caso concreto dell utilizzo del tool con relativa discussione dei risultati ottenuti (capitolo 5). 26

27 Capitolo 2 Infrastrutture di virtualizzazione L'informatica odierna è sempre più attenta a nuove forme di distribuzione dei carichi di lavoro, sia per massimizzare l'utilizzo di ogni singola risorsa, sia per economizzare la gestione e i costi dei mezzi a disposizione. Per questo motivo oggi si ricorre sempre più spesso a termini tecnici quali cloud computing e virtualizzazione, spesso senza essere effettivamente consci del loro significato profondo, delle implicazioni e dei benefici tecnologici che queste metodologie apportano. Concentrandosi sul solo aspetto della virtualizzazione, è riduttivo accostare tale termine unicamente alla sfera dei server e degli altri processi che avvengono in queste macchine. Infatti, "virtualizzare", cioè applicare il principio per cui si genera una versione simulata di una risorsa effettivamente esistente dal punto di vista fisico, non è da riferirsi soltanto al mondo dei server. Quest'ultima è una declinazione specifica del principio e non una sua definizione. In generale vale che qualsiasi sia la risorsa a disposizione, questa possa essere teoricamente virtualizzata, sia essa software o hardware. Partendo da questo 27

28 presupposto, diverrà ancora più semplice comprendere le differenti forme di virtualizzazione oggi esistenti, che coinvolgono diversi tipi di risorse. 2.1 Che cos è la virtualizzazione? La virtualizzazione è concettualmente simile all emulazione. Con l emulazione, un sistema finge di essere un altro sistema. Con la virtualizzazione, un sistema finge di essere due o più repliche dello stesso sistema. Molti degli attuali sistemi operativi prevedono meccanismi di virtualizzazione delle risorse. Ciascun processo in esecuzione immagina di essere l unico e quindi di avere l intera macchina a disposizione. La CPU e la memoria sono virtualizzate. Se un processo tenta di impossessarsi indefinitamente della CPU, il sistema operativo ne effettua la prelazione in favore di un altro processo in modo da garantire una equa condivisione delle risorse tra i processi. Similmente, un processo in esecuzione, possiede un proprio spazio d indirizzamento virtuale mappato in memoria fisica dal sistema operativo: il processo ha l illusione di avere l intera memoria a disposizione. Anche i dispositivi hardware sono virtualizzati: un processo può usare le Berkeley Socket API per accedere a interfacce di rete senza preoccuparsi delle altre applicazioni Perché virtualizzare? Il motivo principale è lo stesso che ha dato luogo al multitasking nel caso dei sistemi operativi: i computer hanno una potenza di calcolo ben superiore a quella necessaria per eseguire un singolo task. Un numero sempre crescente di organizzazioni si ritrova attualmente a dover gestire una certa quantità di server ciascuno dei quali ospita un 28

29 singolo task: la virtualizzazione offre la possibilità di eseguire su una singola macchina fisica un certo numero di server virtuali garantendo una migliore utilizzazione delle risorse fisiche e mantenendo allo stesso tempo un livello di sicurezza elevato grazie a politiche che permettono di isolare tra loro macchine ospitate sullo stesso server Macchina virtuale Per prima cosa, è proposta in seguito una definizione formale di Virtual Machine Monitor (o Hypervisor). Un Virtual Machine Monitor (VMM) è uno strato software che si pone tra uno o più sistemi operativi e l'hardware, dando l'illusione che ciascun sistema operativo in esecuzione detiene il controllo dell'hardware sottostante. Nella fattispecie, è lo stesso Hypervisor ad avere il controllo della macchina fisica, garantendo una condivisione della stessa tra i vari sistemi operativi ospiti. Si definisce macchina virtuale un contenitore software, totalmente isolato, che può eseguire i propri sistemi operativi e applicazioni come fosse un computer fisico. Una macchina virtuale si comporta esattamente come un computer fisico ed è dotata di propri CPU, RAM, disco rigido e NIC (Network Interface Card) virtuali basati, ad esempio, su software. Un sistema operativo non è in grado di distinguere una macchina virtuale da una macchina fisica, né possono farlo le applicazioni o altri computer in rete. La stessa macchina virtuale si comporta come se fosse un vero e proprio computer, nonostante sia costituita interamente di software e non contenga in alcun modo componenti hardware. 29

30 2.1.4 Cenni storici L'introduzione del concetto di virtualizzazione risale agli anni '60, dove fu introdotto come paradigma per il partizionamento delle costose risorse hardware tra utilizzatori diversi. Un caso concreto è rappresentato dal sistema IBM CP/CSM. Si tratta di un meccanismo ripartito su due livelli: un componente denominato control program esegue direttamente sull'hardware svolgendo il ruolo di VMM (virtual machine manager), mettendo a disposizione diverse interfacce al livello superiore denominato conversational monitor system, ovvero un sistema operativo replicato su ciascuna macchina virtuale. L'evoluzione di tale meccanismo si concretizza nel VM/370 che, alle caratteristiche del suo predecessore, aggiunge la possibilità di eseguire sistemi operativi diversi sulla medesima macchina virtuale. Gli anni '70 sono caratterizzati dalla massiccia diffusione dei sistemi operativi multitasking. Negli anni '80/'90, complice un forte abbattimento dei costi dell'hardware, si assiste a un parziale abbandono delle tecniche di virtualizzazione soprattutto per quanto riguarda l'infrastruttura server. Sono gli anni in cui vige il paradigma one application, one server che comporta, di contro, un incremento massiccio di server fisici da configurare e un sottoutilizzo delle risorse hardware tant'è che alla fine degli anni '90 si sente, sempre più forte, la necessità di razionalizzare le risorse facendo tornare di impeto le tecniche di virtualizzazione lato server. 30

31 2.1.5 Alcuni esempi di virtualizzazione Facendo riferimento ad un generico sistema computer la virtualizzazione può essere applicata a tre livelli: 1. Linguaggi ad alto livello; 2. Sistema Operativo; 3. Hardware Virtualizzazione applicata ai linguaggi di alto livello Il linguaggio Java rappresenta uno degli esempi di maggiore successo per quel che riguarda la virtualizzazione applicata ai linguaggi di alto livello. La macchina virtuale java si occupa di eseguire programmi tradotti in bytecode dopo una prima compilazione. La chiave della portabilità di Java consiste nella disponibilità di implementazioni della macchina virtuale per diversi ambienti operativi come recita lo slogan write once, run everywhere (scrivi una volta, esegui dappertutto). La macchina virtuale realizza, infatti, un ambiente di esecuzione omogeneo, che nasconde al software Java (e quindi al programmatore) qualsiasi specificità del sistema operativo sottostante. 31

32 Figura 2.1 Un esempio di virtualizzazione a livello applicativo: Java La virtualizzazione dei sistemi operativi Come riportato nell introduzione, lo scenario su cui sono stati condotti i test prevede un certo numero di macchine virtuali (ciascuna delle quali ospita a sua volta un sistema operativo), in esecuzione su una certa macchina fisica. A fare da collante tra macchine virtuali e macchina fisica ritroviamo uno strato software denominato hypervisor, che si occupa, tra le altre cose, di gestire la condivisione delle risorse fisiche tra i vari sistemi operativi. Attualmente, una delle aree nella quale molte aziende dell information technology stanno concentrando il loro impegno è proprio la virtualizzazione dei sistemi operativi. Gli ambiti applicativi delle macchine virtuali sono molteplici ed eterogenei fra loro, poiché la virtualizzazione sta diventando sinonimo di sicurezza informatica ed affidabilità del sistema. L hypervisor può, infatti, controllare ed interrompere eventuali attività pericolose, e ciò fa sì che si usino macchine virtuali 32

33 sempre più frequentemente in ambito di ricerca e collaudo di software. Uno sviluppatore di software potrà quindi eseguire la sua applicazione in diversi ambienti senza dover disporre di più macchine fisiche. Un amministratore di sistema potrà testare uno scenario complesso che vede interagire più servizi su host diversi, ricreando tale scenario su più macchine virtuali (VM) ospitate in una singola macchina fisica. È di seguito riportato un elenco dei vantaggi derivanti dall utilizzo di soluzioni basate sulla virtualizzazione. 1. Aumento dell affidabilità del sistema: sarà, infatti, possibile dedicare una macchina virtuale all esecuzione di pochi servizi che notoriamente non vanno in conflitto tra di loro. Inoltre l hypervisor isolerà le macchine guest in esecuzione sullo stesso host affinché eventuali problemi che compromettono il funzionamento di una singola macchina virtuale, non influenzino la stabilità delle altre; 2. Consolidamento dei server: Molte aziende hanno visto crescere vistosamente il numero dei server proprio a causa dell aumento dei servizi da fornire ai propri utenti. Attraverso la virtualizzazione si possono eseguire più macchine virtuali nella stessa macchina fisica riducendo drasticamente il numero di server; 3. Riduzione del Total Cost of Ownership (TCO): il consolidamento ad un numero inferiore di server permette una notevole riduzione dei costi legati all energia utilizzata per alimentare i server stessi e per mantenere la temperatura ambientale adatta alle sale server. Inoltre si riducono i costi di acquisto e i canoni di manutenzione dei server fisici; 33

34 4. Disaster Recovery: l intero sistema operativo guest può essere facilmente salvato e ripristinato riducendo notevolmente i tempi d indisponibilità in caso di guasto; 5. Alta disponibilità: se è presente un infrastruttura di server fisici con caratteristiche hardware tra loro compatibili e questi server condividono una area dati (storage) sulla quale risiedono le macchine virtuali, sarà possibile spostare l esecuzione di una macchina virtuale su un altro host in caso di failure. Alcuni sistemi prevedono lo spostamento automatico delle macchine virtuali tra i vari host in funzione al carico; 6. Esecuzione di applicazioni legacy: è frequente che alcune organizzazioni utilizzino applicazioni sviluppate per sistemi operativi che girano su hardware ormai obsoleto, non supportato o addirittura introvabile. Attraverso la virtualizzazione si possono continuare ad utilizzare quelle applicazioni che diversamente dovrebbero essere migrate ad una architettura più attuale affrontando i costi relativi al porting e al debug Tipi di virtualizzazione In letteratura sono proposti diversi approcci per la virtualizzazione. Tutte tecniche di virtualizzazione ad oggi impiegate danno l illusione di utilizzare un sistema operativo stand alone, non virtualizzato. Tali tecniche sono: 1. Emulazione: Con l emulazione l hypervisor ha il ruolo di simulare l intero hardware set in modo da permettere al sistema operativo di essere eseguito senza modifiche. Il software di virtualizzazione ha il compito di esibire al 34

35 sistema operativo guest un architettura hardware completa a lui nota, indipendentemente dall architettura hardware presente sulla macchina host. Figura Emulazione I limiti in termini di prestazioni e di funzionalità di quest approccio sono facilmente intuibili: gli emulatori, infatti, offrono al sistema operativo guest un architettura hardware standard impedendo quelle che potrebbero essere le funzionalità alle quali si è abituati, ad esempio quelle implementate in hardware. Inoltre, l emulatore deve provvedere all interfacciamento della CPU, della memoria e dell I/O tra sistema host e sistema guest. Per quanto riguarda la memoria, ciascuna macchina virtuale riceve una sequenza di indirizzi che utilizza in modo esclusivo; il ruolo dell emulatore consiste nel sommare all indirizzo della cella richiesta una costante che rappresenta l entry dell area di memoria assegnata alla macchina virtuale. Un modo di gestire la CPU invece, consiste nell interpretare il flusso di istruzioni provenienti dal sistema guest ed eseguire sul processore host una serie di istruzioni semanticamente equivalenti. Questa strategia ha come effetto collaterale un notevole calo di prestazioni ed è pertanto inefficace soprattutto 35

36 quando bisogna emulare sistemi guest che richiedono processori di velocità equivalente al processore dell host. 2. Full Virtualization: la Full Virtualization detta anche Native Virtualization è molto simile all emulazione. Come nell emulazione, i sistemi operativi guest girano senza alcuna modifica in macchine virtuali ospitate sul sistema host. La differenza rispetto all emulazione risiede nel fatto che i sistemi operativi guest devono essere compatibili con l architettura hardware della macchina fisica. In questo modo molte istruzioni possono essere eseguite direttamente sull hardware senza bisogno di un software di traduzione garantendo prestazioni superiori rispetto all emulazione. Esempi di software che utilizzano la full virtualization sono VMware, Parallel Desktop, Virtual Box, Win4Lin Pro e Xen, limitatamente ai sistemi operativi proprietari non modificabili. Figura 2.3 Full Virtualization 3. Paravirtualization: Un altra tecnica di virtualizzazione è la paravirtualization. L hypervisor presenta alle macchine virtuali una versione modificata dell hardware sottostante, mantenendone tuttavia la medesima architettura. Il sistema operativo in esecuzione sulle macchine virtuali è invece modificato per evitare alcune particolari chiamate di sistema. Non viene invece modificata 36

37 l Application Binary Interface e pertanto le applicazioni possono essere eseguite senza modifiche. Questa tecnica permette di ottenere un decadimento delle prestazioni minimo rispetto al sistema operativo non virtualizzato, dato che le istruzioni provenienti dalle macchine virtuali sono eseguite quasi tutte direttamente sul processore senza che intervengano modifiche. Esempi di paravirtualizzazione sono Xen e User-mode Linux. Figura 2.4 Paravirtualization 4. Operating System level Virtualization: questo approccio non prevede l utilizzo di alcun Hypervisor ma la virtualizzazione è ottenuta mediante la condivisione dell immagine di un sistema operativo tra più guest. Tali sistemi guest si possono considerare a tutti gli effetti istanze del sistema operativo host con un proprio file system, configurazione di rete e applicazioni. La possibilità di condividere la memoria tra i vari sistemi host costituisce il principale vantaggio di questa tecnica. Inoltre, è previsto un significativo risparmio di memoria dovuto al fatto che i vari sistemi guest non necessitano un kernel privato, ma ne utilizzeranno uno in comune. Tuttavia, l impossibilità di eseguire su un unico host macchine con sistemi operativi diversi costituisce un limite evidente dell Operating System Virtualization. Altro effetto collaterale è il ridotto 37

38 isolamento tra le macchine guest: una qualsiasi anomalia di un solo guest può influire negativamente sugli aspetti sia comportamentali sia prestazionali delle altre macchine. Figura 2.5 Operating System Level Virtualization 38

39 2.2 Xen hypervisor Xen è un hypervisor nato da un progetto open source iniziato presso l università di Cambridge. É alla base di innumerevoli applicazioni commerciali e open source quali server virtualization, Infrastructure as a Service (IaaS), desktop virtualization, security applications, sistemi embedded. É, inoltre, alla base dei principali sistemi di cloud computing Architettura L'ambiente virtuale Xen è costituito da diverse componenti che cooperano tra loro. Figura 2.6 Architettura di Xen Con riferimento alla figura 2.6 l architettura di Xen prevede: 1. L'hypervisor Xen che, come più volte detto, poggia direttamente sull'hardware (bare metal hypervisor) occupandosi dello scheduling della CPU e del partizionamento della memoria tra le varie macchine virtuali in esecuzione. Il suo compito principale è quello di garantire l'esecuzione di più macchine virtuali 39

40 su una certa infrastruttura hardware, offrendo, quindi la condivisione delle risorse fisiche a disposizione. È da notare che l hypervisor non si occupa delle normali operazioni di I/O come l accesso alla rete, l accesso allo storage, attività di monitoring, ecc; 2. Domain 0 (o Dom0). Si tratta di una macchina virtuale con kernel Linux modificato. È l'unica macchina virtuale in esecuzione su Xen che gode di speciali privilegi di accesso alle risorse di I/O ed ha, inoltre, la possibilità di interagire con le altre macchine virtuali (Domain U o DomU) in esecuzione. Un qualsiasi ambiente di virtualizzazione basato su Xen richiede la presenza di un Domain 0 prima che qualsiasi altra macchina ospite possa essere avviata. Il Domain 0, prevede, inoltre, la presenza di due driver a supporto delle richieste di accesso al disco e alla rete, generate dai guest domain (il Network Backend Driver e il Block Backend Driver). Il Network Backend Driver comunica direttamente con l'interfaccia di rete locale (fisica, non virtuale) con lo scopo di processare le richieste di accesso alla rete, provenienti dai DomU. Il Block Backend Driver comunica con il disco locale e legge o scrive i dati sui volumi in base alle richieste provenienti dai Domain U. Tra le altre cose, il Dom0 è responsabile di compiti amministrativi quali la creazione di un DomU o la gestione dei DomU correntemente in esecuzione. 3. Domain U. Questo tipo di dominio non avendo accesso diretto all'hardware (contrariamente al Dom0), è spesso identificato col termine di dominio non privilegiato (unprivileged domain). A tal proposito, occorre distinguere tra i Domain U PV (paravirtualizzati) e i Domain U HVM (Hardware Virtual Machine). I Domain U PV sono quelle macchine virtuali che utilizzano la tecnica della paravirtualizzazione. Il loro kernel è stato modificato per ottimizzarne 40

41 l esecuzione su Xen Hypervisor. Si tratta di macchine virtuali con sistemi operativi Linux, Solaris, FreeBSD e altri sistemi open source. A livello accademico è stata creata anche una versione paravirtualizzata di Windows XP in collaborazione con Microsoft. I Domain U HVM sono invece macchine virtuali completamente virtualizzate in quanto dotate di sistemi operativi con kernel non modificabile, ad esempio tutti i sistemi operativi di Microsoft: quello appena citato è senza dubbio uno dei maggiori benefici apportati dall approccio HVM. I domini paravirtualizzati sono coscienti che stanno operando su Xen Hypervisor e che ci sono altri Domain U in esecuzione. Sono dotati quindi di due driver per gestire le loro operazioni sulla rete e sullo storage che s interfacciano con i driver di back end presenti sul Dom0. Diversamente, i Domain U HVM Guest non hanno questi driver. La comunicazione con le risorse di I/O avviene invece attraverso un processo speciale chiamato Qemu-dm che viene istanziato sul Dom0: ogni Domain U HVM Guest in esecuzione richiede il corrispondente demone Qemu sul Domain 0. Questo demone si occupa di gestire tutte le richieste di accesso al disco e alla rete da parte del domino HVM che, essendo ignaro del fatto che esegue su Xen, accede ai driver dei dispositivi i quali faranno riferimento non alle risorse fisiche bensì a quelle emulate da qemu. Il dominio HVM è caratterizzato, inoltre, da uno strato software detto Xen Virtual Firmware. Si tratta di un bios virtuale che assicura al sistema operativo guest di ricevere, in avvio, tutte le istruzioni che si aspetta, mascherando così l architettura sottostante. 41

42 Figura 2.7 Accesso periferiche dei Dom U HVM Per meglio chiarire il ruolo svolto dal Dom0 e dal DomU (paravirtualizzato) si faccia riferimento allo scenario di figura 2.8 in cui un pacchetto deve essere inviato da un'applicazione che esegue su un DomU. Figura 2.8 Meccanismo split device driver Per prima cosa, detto pacchetto attraversa lo stack TCP/IP, come avverrebbe di norma; alla fine della pila TCP/IP, ad attendere il pacchetto non troviamo il driver 42

43 di rete bensì una routine, denominata Split Device Driver, che si occupa di trasferire i dati provenienti dall'applicazione in un'area di memoria condivisa con il Dom0. L'altra metà dello Spit Device Driver, che si trova nel Dom0, legge i pacchetti dal buffer condiviso trasferendoli al device driver dell'interfaccia di rete (fisica). Il segmento di memoria è stato preventivamente condiviso (tra Dom0 e DomU) usando un meccanismo denominato Xen grant table e pubblicizzato da XenStore (entrambi gli argomenti sono approfonditi in seguito). Si noti che lo split network device è lo stesso indipendentemente dall interfaccia di rete; questo favorisce, tra le altre cose, il porting di sistemi su Xen. In sintesi, un driver prevede tre componenti: 1. lo split driver è tipicamente più semplice possibile; il suo compito principale è quello di trasferire dati dal DomU al Dom0 mediante la condivisione della memoria; 2. il driver reale, che esiste indipendentemente da Xen e che, quindi, non può essere considerato parte di esso; 3. un multiplexer che fa parte, tipicamente, del sistema operativo e si occupa di instradare i dati verso la corretta routine di gestione Configurazioni La configurazione più semplice di Xen prevede il solo Dom0. In questo scenario, Xen si comporta come un hardware abstraction layer. Si tratta di una configurazione non utile in genere. Tipicamente, un sistema Xen possiede almeno un DomU guest in esecuzione (Figura 2.9). 43

44 Figura 2.9 Una semplice configurazione di Xen In questo esempio tutto l'hardware è controllato dall'host nel Domain 0; questo non è sempre l'ideale, infatti, se un driver contiene un bug può andare in crash nel Dom0 causando il crash anche degli altri domini. Pertanto, è spesso utile isolare un driver in un dominio ad esso dedicato. Un driver domain è, quindi, un dominio Xen non privilegiato che è responsabile della gestione di alcuni driver; viene eseguito in un kernel minimale e oltre a disporre del driver del dispositivo mette a disposizione degli altri domini il driver di back-end per il suddetto device. Quindi, se il driver fallisce, gli altri domini (incluso il Dom0) sopravvivono e, quando il driver domain viene riavviato, è possibile usarlo di nuovo. Tale approccio comporta una riduzione del sovraccarico del Dom0 oltre ad un significativo miglioramento del livello di sicurezza: i driver, infatti, sono la principale causa del fallimento di un sistema operativo. Isolare il driver quindi, va a beneficiare sulla sicurezza dell'intero sistema. 44

45 Figura 2.10 Architettura per l esecuzione di applicazioni legacy Un'altra possibile configurazione segue dalla necessità di eseguire applicazioni legacy in concorrenza con applicazioni recenti; in tale circostanza si ricorre a guest non modificabili. Chiaramente, in questo tipo di configurazione, i guest non modificati non usano direttamente gli split device driver. Usano, invece, device driver emulati nel Dom0 come riportato in figura Xen e i meccanismi di protezione dell architettura IA-32 Nel modello di protezione classico tipico delle architetture IA-32 sono previsti quattro livelli di privilegi denominati ring. Il ring con priorità maggiore coincide con lo zero; si tratta del livello in cui il kernel esegue (modo supervisore). Il livello più basso corrisponde al ring tre; è qui che eseguono le applicazioni utente (modo utente). Eseguire alcune istruzioni, denominate privilegiate, nel ring tre comporta la generazione di una trap con conseguente passaggio dal modo utente al modo supervisore. Il ring uno e due non sono stati usati negli anni (ad eccezione di OS/2). 45

46 L'introduzione di un hypervisor al di sotto del sistema operativo viola il principio per cui il sistema operativo deve essere eseguito con il privilegio maggiore. Per proteggere l hypervisor da comportamenti inaspettati dei sistemi operativi guest e per garantire isolamento tra le macchine virtuali, essi devono essere eseguiti con privilegi inferiori. In architetture diverse da IA32 (ad esempio IA64) l'assenza dei ring uno e due imponeva una modifica all'hypervisor Xen (che eseguiva nel ring zero) con il con il conseguente spostamento del sistema operativo nel ring tre (insieme alle applicazioni utente). Il tutto è mostrato in figura Figura 2.11 Utilizzo dei ring nei sistemi con architettura IA64 La presenza di quattro ring (IA32) semplifica l'introduzione di Xen; infatti, basterà spostare il sistema operativo nel ring 1 lasciando il ring 0 all'hypervisor (figura 2.12). 46

47 Figura 2.12 Utilizzo dei ring nei sistemi con architettura IA Gestione della memoria Per quel che concerne la virtualizzazione della memoria, i progettisti di Xen hanno preso due decisioni: 1. I sistemi operativi guest sono responsabili dell'allocazione e della gestione delle tabelle delle pagine hardware, con un minimo coinvolgimento di Xen che garantisce sicurezza e isolamento; 2. Xen occupa una porzione ben definita dello spazio di indirizzamento in modo da evitare il ricorso alla pulizia del Translation Lookaside Buffer (TLB) ogni volta che l'hypervisor è interessato da un cambiamento di contesto. In figura 2.13 sono proposti alcuni scenari che prevedono una diversa gesitone della memoria a seconda dell architettura disponibile: 47

48 1. In presenza di un architettura a 32 bit, Xen occupa i primi 64MB dello spazio di indirizzamento a 4GB; 2. Se l architettura della macchina prevede Physical Address Extension (PAE), Xen avrà a disposizione i primi 168MB. Figura 2.13 Gestione della memoria 48

49 2.2.5 Analogie con i sistemi operativi La scrittura di codice per Xen è, per molti versi, simile alla scrittura di codice per UNIX. La figura 2.14 mostra le analogie tra Xen e un sistema Unix like. Unix System Calls Signals Filesystem POSIX Shared Memory Xen Hypercalls Events XenStore Grant Tables Figura 2.14 Analogie tra Xen e Unix Hypercalls Come accennato nei paragrafi precedenti, siccome il kernel esegue nel ring 1 (nel ring 0 c'è Xen!), non gli è concesso di fare qualsiasi operazione. Qualcosa di simile accade ai programmi che eseguono nello spazio utente (ring 3): effettuare una stampa sullo schermo, inviare dati in rete o leggere un input dalla tastiera sono operazioni non effettuabili in modalità non privilegiata. La soluzione, com'è noto, è quella di usare le system call: si tratta di un meccanismo formale in cui viene chiesto al kernel di eseguire un compito specifico. Le system call lavorano tutte allo stesso modo, indipendentemente dal sistema operativo o piattaforma: 1. Effettuano il push dei parametri nei registri o nello stack; 2. Generano un interrupt software (trap) specifico; 49

50 3. La generazione dell'interrupt comporta il passaggio dal modo di esecuzione utente (non privilegiato) al modo kernel (privilegiato); 4. Con i privilegi ottenuti viene processata la system call; 5. si riporta il sistema al modo di funzionamento utente ritornando il controllo al chiamante. In generale, l'architettura x86 prevede l'utilizzo dell'interrupt 80h per le system call, tuttavia, release recenti prevedono l'utilizzo di istruzioni speciali quali SYSENTER/SYSEXIT o SYSCALL/SYSRET. Nel caso di Xen la soluzione al problema presentato a inizio paragrafo si basa sullo stesso meccanismo sopraesposto. Un sistema guest invoca una hypercall nello stesso modo in cui un'applicazione chiama un system call con la differenza, nel caso delle hypercall, che l'interrupt generato è 82h. Il presente meccanismo di funzionamento è stato in uso fino alla versione 3 di Xen (la versione più recente corrisponde alla 4.2); le successive versioni prevedono un meccanismo basato sulla creazione di un'hypercall page. Si tratta di un'area di memoria mappata nello spazio di indirizzamento di un guest e creata all'avvio del sistema. Una specifica hypercall è eseguita invocandola presso l'indirizzo della hypercall page in cui risiede. La riga 5 di figura 2.15 mostra il meccanismo di invocazione di una hypercall. Nella fattispecie, viene richiamato un indirizzo dato dal numero della hypercall che s'intende richiamare moltiplicato per 32. Poiché la dimensione di una pagina sull'architettura x86 è di quattro kilobyte, si possono avere al massimo

51 hypercall. Al momento della scrittura esistono 37 hypercall più altre 8 dipendenti dalla specifica architettura. 1 #define _hypercall0(type, name) \ 2 ({ \ 3 HYPERCALL_DECLS; \ 4 HYPERCALL_0ARG(); \ 5 asm volatile ( HYPERCALL \ 6 : HYPERCALL_0PARAM \ 7 : HYPERCALL_ENTRY(name) \ 8 : HYPERCALL_CLOBBER0); \ 9 (type) res; \ 10 }) 11 Figura 2.15 Esempio macro hypercall0 Per fare un paragone, la versione 7 del sistema operativo Unix supporta ben 64 system call, mentre in un moderno kernel FreeBSD sono implementate all'incirca 51

52 450 system call. Il fatto di aver un numero ristretto di hypercall risponde a pieno alla filosofia di Xen, less is more, la cui traduzione molto informale, potrebbe essere: l'hypervisor non dovrebbe fare nulla che non sia strettamente necessario al funzionamento dei guest. Per ragioni di efficienza, la filosofia di Xen prevede alcune hypercall che eseguono in batch più operazioni (scheduling, aggiornamento della tabella delle pagine...) in un solo colpo. Le successive due linee di codice comunicano al compilatore GCC i registri del processore da utilizzare. Il valore di ritorno ( res) è memorizzato nel registro EAX e l'argomento in EBX; nel caso di hypercall con più di un argomento sono utilizzati anche gli altri registri come ad esempio ECX. Quando si scrive del codice in ambiente utente, non è usuale entrare manualmente nell'ambiente kernel. Il passaggio dal modo di esecuzione user al modo kernel è ottenuto tramite delle funzioni wrapper, denominate system call, che fanno da tramite tra i due ambienti dei esecuzione. Allo stesso modo si comportano le hypercall che consentono, con riferimento all'architettura x86, il passaggio dal ring 1 (kernel) al ring 0 (hypervisor). Torneremo a parlare dell'hypercall nei paragrafi successivi in maniera più approfondita Events In un sistema Unix, è possibile utilizzare i segnali per garantire la comunicazione tra due entità; si tratta di un meccanismo asincrono che permette ad una entità qualsiasi, esterna ad un processo, di avvertire lo stesso processo circa 52

53 l'occorrenza di un dato evento. L'entità esterna può essere il kernel o un altro processo. Il meccanismo analogo in Xen è noto come event mechanism. Una delle prime cose che un kernel guest deve fare all'avvio è di registrare una callback che sarà usata per la notifica di eventi. Quando un guest riceve la notifica di un evento, vengono settati dei flag per indicare, appunto, che detto evento si è verificato. Il guest può gestire tale situazione in due modi: può mascherare la notifica dell'evento e verificare periodicamente se ci sono messaggi pendenti, oppure può utilizzare un meccanismo di notifica asincrono. Gli eventi possono essere generati direttamente da Xen e possono rappresentare interruzioni hardware o virtuali, o da altri guest. Gli eventi Xen possono essere utilizzati per creare un canale tra guest in cui viaggiano informazioni riguardo, ad esempio, lo stato di risorse condivise. La comunicazione tra due guest richiede 5 passi: 1. Il guest ricevente crea una nuova porta; 2. Il guest ricevente comunica l'esistenza della porta appena creata (ad esempio attraverso XenStore); 3. Il guest mittente crea, a sua volta, una nuova porta qualora non ne avesse una libera; 4. il guest mittente associa la porta precedentemente creata, ad ad una sorgente di eventi (ad esempio, un IRQ fisico, un IRQ virtuale, o un porto di un altro dominio); nel nostro caso la porta viene associata a quella creata sul lato ricevente; 5. Solo a questo punto è possibile utilizzare il canale per la comunicazione di eventi. 53

54 Grant tables Il modello basato sui segnali di Unix è ottimo per notifica veloce di eventi ma non è sufficiente per costruire un meccanismo per la comunicazione tra processi (IPC). A tale scopo esistono svariati approcci quali code di messaggi o ancora memoria condivisa. In ambiente Xen la comunicazione interdominio avviene mediante le grant tables. Si tratta di un meccanismo che prevede la condivisione di aree di memoria tra domini. La tecnica dello split driver è realizzata proprio grazie alle grant tables. Come accennato nei precedenti paragrafi, un dominio non privilegiato s interfaccia con un driver virtuale che a sua volta comunica, tramite memoria condivisa, con il driver reale residente nel dom0. Ciascun dominio ha la propria grant table; è una struttura dati condivisa con Xen che permette a ciascun dominio di comunicare all'hypervisor quali permessi possiedono gli altri domini sulle sue pagine. Le voci presenti nella grant table, note come grant reference, sono degli interi che indicano i privilegi che un concessionario mette a disposizione sull'area di memoria che intende condividere. Un grant reference incapsula, inoltre, altre informazioni che esentano un dominio dal conoscere il reale indirizzo della pagina condivisa. Questo offre la possibilità di condivisione della memoria anche tra domini fully virtualized XenStore XenStore è uno spazio di memorizzazione d informazioni condivise tra i domini. È pensato per le notifiche di informazioni di configurazione e di stato piuttosto che per grandi trasferimenti di dati. Ogni dominio possiede una sorta di pseudo file system 54

55 analogo a procfs dei sistemi Unix like. Quando sono modificati i valori dello store, i driver corrispondenti vengono avvertiti. Lo store conta tre percorsi principali: - /vm memorizza le informazioni di configurazione dei domini, ad esempio il nome simbolico del dominio (ssidref), il numero di cpu dedicate (vpcpu_avail), la memoria disponibile (memory). Altri tipi di informazioni presenti riguardano il comportamento da assumere in corrispondenza di un determinato stato della macchina, cioè: le azioni da eseguire quando il dominio riceve una richiesta di reboot (destroy o restart), le azioni da svolgere quando il dominio riceve una richiesta di halt (destroy o restart) e le azioni da compiere quando il dominio va in crash (destroy o restart); - /local/domain contiene le informazioni sul dominio correntemente in esecuzione. - /tool contempla informazioni riguardo I tool di supporto. 55

56 2.2.6 Approfondimento sulle hypercall Nei seguenti paragrafi è proposta una descrizione approfondita di alcune hypercall, oggetto dei test descritti nei capitoli successivi Virtual CPU setup In fase di avvio, il sistema operativo ospite ha bisogno di inizializzare la/le CPU virtuali su cui dovrà eseguire. Quest operazione include la configurazione dell Interrupt Descriptor Table virtuale in modo che ciascun sistema operativo guest possa gestire gli interrupt, i page fault, etc. Un atra operazione compiuta in fase di avvio dal sistema operativo guest è il settaggio di alcune callback utilizzate da Xen per la notifica degli eventi. HYPERVISOR_set_callbacks(unsigned long event_selector, unsigned long event_address, unsigned long failsafe_selector, unsigned long failsafe_address) Figura 2.16 HYPERVISOR_set_callbacks L hypercall di figura 2.16 registra una callback ordinaria e una fail-safe per l elaborazione degli eventi. Il valore di event_address specifica l indirizzo della routine di gestione e dispatching dell evento. Il failsafe_address specifica, invece, 56

57 un diverso entry point che è usato solo se, a causa di un guasto, Xen tenta di utilizzare la callback ordinaria. Una volta inizializzate le callback, il sistema operativo guest può installare la IDT virtuale con la seguente hypercall: static inline int HYPERVISOR_set_trap_table(struct trap_info *table) { return _hypercall1(int, set_trap_table, table); } Figura 2.17 HYPERVISOR_set_trap_table Ogni voce nella tabella include il numero del vettore dell eccezione con il corrispondente entry point della routine di gestione. In ambiente Xen, la maggior parte dei sistemi operativi ospiti possono utilizzare gli stessi handler come avverrebbe in presenza di hardware reale Scheduling e timer Lo scheduling dei domini in Xen avviene in accordo a parametri impostati nel Dom0. Tuttavia, un dominio può esplicitamente scegliere di controllare alcuni dei suoi comportamenti attraverso la seguente hypercall: HYPERVISOR_sched_op(int cmd, void *arg) 57

58 Mediante la sua invocazione viene effettuata una richiesta di un operazione di scheduling all hypervisor. A titolo di esempio si riporta in seguito l elenco di valori che il parametro cmd può assumere: - SCHEDOP_yeld: rilascia la CPU ad un altro dominio runnable; - SCHEDOP_block: rimuove il dominio chiamante dalla coda dei domini runnable e porta tale dominio nello stato di sleep; - SCHEDOP_shutdown: ferma l esecuzione del dominio chiamante notificando l evento al controller; - SCHEDOP_poll: interroga una serie di event-channel ports restituendo il controllo al chiamante non appena c è un evento pendente; - SCHEDOP_remote_shutdown: l utilizzo principale è quello di interpretare richieste di arresto nonché le motivazioni da parte di domini fully virtualized; In particolare, nel caso di SCHEDOP_shutdown, le motivazioni dello spegnimento del dominio possono essere: - il dominio si spegne normalmente ; - il dominio si riavvia; - il dominio si autosospende; - il dominio va in crash; - il watchdog timer è scaduto. 58

59 Gestione delle tabelle delle pagine Dato che un sistema operativo guest ha privilegi di sola lettura alle sue tabelle delle pagine, Xen deve essere coinvolto ogni volta che si effettua una cambiamento in memoria. La seguente hypercall: HYPERVISOR_mmu_update(struct mmu_update *req, int count, int *success_count, domid_t domid) consente di modificare le tabelle delle pagine, effettuare il flush del TLB, installare una nuovo puntatore base di una tabella delle pagine, e molto altro. Ad esempio, nel caso di aggiornamento della tabella delle pagine di un dominio, count rappresenta il numero di modifiche da effettuare in batch, success_count indica il numero di aggiornamenti effettuati con successo, domid identifica il dominio che richiede tali aggiornamenti. struct mmu_update { uint64_t ptr; /* Machine address of PTE. */ uint64_t val; /* New contents of PTE. */ }; Figura 2.18 struct mmu_update Ciascun elemento di req [] contiene un puntatore e un valore (figura 2.18). In particolare, gli ultimi 2 bit meno significativi di ptr permettono di discriminare il tipo aggiornamento che s intende effettuare: 59

60 - MMU_NORMAL_PT_UPDATE aggiorna una page directory o una page table identificata da val; - MMU_MACHPHYS_UPDATE aggiorna l entry di una tabella machine-tophysical; - MMU_EXTENDED_COMMAND si occupa di eseguire operazioni che coinvolgono il dispositivo MMU. Tali operazioni sono: l aggiornamento del registro cr3, il flushing della cache, l installazione di una nuova Local Descriptor Table, etc. HYPERVISOR_mmu_update consente di effettuare più aggiornamenti in un sol colpo; tuttavia, esistono casi in cui è richiesta la modifica di una sola entry in una data tabella delle pagine. In tale circostanza è possibile ricorrere a: static inline int HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val, unsigned long flags) che aggiorna una voce della tabella delle pagine va al valore val. Come la hypercall citata in precedenza, Xen si accerta che la modifca richiesta sia sicura prima di applicarla. Il parametro flags consente, inoltre, di definire il tipo di flush della TLB da compiere in seguito. Infine, se un dominio ha sufficienti privilegi, può, occasionalmente, manipolare le pagine degli altri domini utilizzando: HYPERVISOR_update_va_mapping_otherdomain 60

61 Quest operazione privilegiata è effettuata, ad esempio, dal driver virtuale di backend per trasferire dati all altra sezione del driver (front-end) presente in un altro dominio Comunicazione interdominio Xen mette a disposizione un meccanismo asincrono di notifica servendosi degli event channels. Ciascun dominio ha un set di porti che possono essere associati ad una sorgente di eventi (event source) quali una IRQ virtuale, una IRQ fisica o una porta di un altro dominio. La comunicazione tra due domini avviene a partire dalla seguente hypercall: HYPERVISOR_event_channel_op(int cmd, void *arg) Dove il valore di cmd discrimina sette possibili operazioni: - alloc_unboud consente ad un dominio di istituire un porto da utilizzare successivamente per la comunicazione con un altro dominio; - bind_virq effettua il bind di un porto locale con un IRQ virtuale; - bind_pirq effettua il bind di un porto locale con un IRQ fisico; - bind_interdomain costruisce un canale di comunicazione, nel gergo di Xen event cannel, tra due domini; in generale, il dominio effettua questa operazione solo dopo aver creato un porto unbound mediante alloc_unbound; - close chiude un canale tra due domini; - send invia un evento all altro capo del canale; - status determina lo stato corrente del porto locale. 61

62 HYPERVISOR_multicall La trattazione delle hypercall termina con la discussione di quella che sarà, più di tutte, interessata nella fase di testing. Si tratta di HYPERVISOR_multicall: HYPERVISOR_multicall(void *call_list, int nr_calls) Con questa hypercall è possible eseguire in batch un certo numero di hypercall, nr_calls, in precedenza caricate in un buffer puntato da call_list. Questo tipo di ottimizzazione si rivela particolarmente utile nei casi di context switch, dove, la nuova macchina in esecuzione richiede una serie operazioni preliminari svolte dalle singole hypercall. Un meccanismo analogo è previsto con le operazioni di aggiornamento delle tabelle delle pagine che possono essere eseguite in lotti attraverso HYPERVISOR_mmu_update. Questo stratagemma va a beneficio delle prestazioni poiché richiede meno transizioni della CPU (dal ring 1 o 3 a 0) rispetto all approccio di eseguire le stesse operazioni attraverso singole hypercall. struct multicall_entry { unsigned long op, result ; unsigned long args [ 6 ] ; } ; Figura 2.19 struct multicall_entry La figura 2.19 mostra il formato degli elementi dell array puntato da call_list. Il campo op detiene il numero dell hypercall (codice operativo), cioè il valore che conterrebbe il registro EAX nel caso di hypercall singola; result conterrà il valore 62

63 di ritorno prodotto dall esecuzione dell hypercall op, che contrariamente al caso di singole chiamate non andrà a sovrascrivere il registro EAX; args detiene gli argomenti previsti per l hypercall op. Inoltre, è importante ricordare che, diversamente dal caso di singole hypercall, un guest può essere interrotto nel mezzo dell esecuzione di una multicall. Il discorso sul miglioramento delle prestazioni apportate da questo approccio va a vantaggio dei domini paravirtualizzati dato che simili meccanismi non sono previsti dall altra tipologia di macchine virtuali supportate da Xen (HVM domain). 63

64 Capitolo 3 Tool di fault injection Il contributo principale del presente lavoro di tesi è un tool per l'iniezione di guasti su macchine che eseguono in ambiente virtualizzato Xen. Esso comprende una patch da applicare al kernel e una serie di script di supporto. Come già accennato nei capitoli precedenti, si vuole sperimentare una tecnica di iniezione di guasti la cui finalità è quella di consentire all'utente l applicazione di diverse tipologie di fault nello strato software che interfaccia il sistema operativo ospite con l infrastruttura di virtualizzazione. Tale interfaccia è costituita da funzioni note come hypercall il cui comportamento è analogo a quello delle system call. 3.1 Scenario di riferimento In figura 3.1 è rappresentato un tipico scenario in cui sono presenti tre domini: 1. Un dominio privilegiato (dom0) presso cui esegue il modulo front-end del tool; 2. Un dominio target non privilegiato (al centro) su cui eseguono il modulo di back-end del tool e il modulo che sottopone tale dominio a carichi di lavoro 64

65 allo scopo di simulare condizioni reali di funzionamento; 3. Un terzo dominio non privilegiato su cui esegue, eventualmente, un certo workload. In rosa è evidenziato il punto di iniezione su cui agisce il tool. Figura Scenario di riferimento Le caratteristiche principali del tool sono: 1. Possibilità di compiere un profiling preventivo volto all'individuazione delle hypercall invocate con maggiore frequenza in modo da poter condurre, in seguito, un oculata campagna di fault injection; 2. Scelta del tipo di fault da iniettare con la possibilità di specificare parametri quali probabilità e numero di occorrenze del fault in modo da poter simulare 65

66 molteplici condizioni di funzionamento; 3. Raccolta dei log generati dalla macchina sottoposta al test. 3.2 Architettura Con riferimento alla figura 3.2, il tool si compone di diversi moduli aventi specifiche funzioni: Figura Architettura del tool 66

67 1. Controller, residente nel Dom0, adibito al lancio dello script di iniezione e al monitoraggio dello stato della macchina target predisponendone, eventualmente, il riavvio in caso di crash; 2. Monitor, residente nel Dom0, raccoglie i log del DomU a valle dell'applicazione del singolo fault; 3. Data collector, residente nel Dom0, studia i dati raccolti dal monitor producendo dei report; 4. Workload Generator; genera carichi di lavoro sulla macchina target, ossia un insieme di input assimilabile a quello che si registra in un esecuzione tipica; è possibile eseguire questo modulo sia sulla macchina target che su quella che inietta i fault. 5. Fault injector, esegue nella macchina target; è il modulo responsabile dell'iniezione dei fault inviati dal modulo controller tramite connessione ssh; 6. Profiler; si tratta di uno script che si occupa di individuare le hypercall invocate con maggiore frequenza. I report da esso prodotti costituiscono la base di partenza per la conduzione dalla campagna di fault injection; 7. Target system, sistema da testare; nella presente implementazione, si tratta di una macchina virtuale con kernel Linux. Tornando alle funzionalità offerte dal tool è di seguito riportata una descrizione più accurata di ciascuna di esse. 3.3 Profiling La creazione di una campagna di test passa attraverso un'attività di studio la cui finalità è quella di individuare i punti in cui verranno applicati i fault. Con riferimento allo scenario proposto nei paragrafi precedenti, un possibile approccio consiste 67

68 nell'individuare le hypercall invocate con maggiore frequenza avendo sottoposto il sistema ad uno specifico workload. A tal proposito il tool, è corredato di uno script realizzato con SystemTap che adempie i suddetti scopi. SystemTap è uno strumento di analisi e probing che permette di studiare e monitorare in dettaglio le attività del sistema operativo (in particolare, il kernel). Fornisce informazioni simili a quelle generate da altri strumenti come netstat, ps, top e iosat introducendo ulteriori opzioni per il filtraggio delle informazioni raccolte. A corredo di SystemTap vi è un'utility denominata stap che permette di eseguire degli script con lo scopo di monitorare determinate parti del sistema operativo in oggetto. Tali script saranno poi tradotti in codice C e compilati in un modulo che verrà caricato nel kernel per svolgere le operazioni richieste. Le operazioni da svolgere in questo caso consistono nell'individuare quali hypercall sono maggiormente invocate. Avendo sottoposto il sistema target a un determinato workload si lanciano in sequenza degli script SystemTap ciascuno dei quali produce in output il numero di volte, nell'arco del periodo di osservazione, in cui viene invocata la hypercall i-esima. Si riporta di seguito il codice dello script che legge l'hypercall i-esima da un file (hypercall.txt) e richiama lo script di probing di SystemTap passando come argomento la suddetta hypercall. Lo script SystemTap effettua il probing dell'hypercall per un intervallo di 60 secondi al termine del quale scrive su un file il numero di volte in cui la funzione in questione è stata richiamata. Avendo, a questo punto, a disposizione informazioni più dettagliate riguardo il comportamento del sistema è possibile realizzare un testbed accurato. 68

69 #!/bin/bash while read line do echo "${line}"; var="${line}" echo "stap -v probe_generic.stp" $var stap -v probe_generic.stp $var >> generic.txt done < hypercall.txt Figura Script profiling global syscalllist probe kernel.function(@1) //@1 raccoglie l'hypercall corrente di cui fare probing { syscalllist++ } probe timer.ms(60000) { printf("%s %d\n",@1, syscalllist) exit() } Figura Script SystemTap profiling 69

70 3.4 Scelta dei fault La seconda fase della sperimentazione consiste nell applicazione dei fault alle hypercall target individuate nel passaggio precedente. A tal proposito il tool prevede uno script da eseguire nella macchina da testare. Detto script ha il compito di passare al filesystem virtuale, debugfs, i parametri caratterizzanti il singolo fault. Il presente tool, infatti, nasce per estensione del tool d iniezione di guasti già presente in ambiente Linux. Questo tool, consente di iniettare uno specifico fault offrendo la possibilità di stabilire le modalità temporali e spaziali con cui deve verificarsi il guasto; è possibile impartire tali istruzioni direttamente dallo spazio utente servendosi del file system virtuale. Mantenendo intatto l'approccio originario, il tool di iniezione guasti è stato arricchito in modo da poter applicare fault anche in ambiente virtualizzato. In particolare è stato aggiunto un nuovo tipo di guasto (denominato hfail) al quale sono stati associati nuovi parametri caratterizzanti. Tali parametri sono: 1. hypercall specifica l'id dell'hypercall a cui si vuole applicare il guasto; nel caso venga indicata una hypercall non contemplata dal tool il fault non avrà luogo; 2. posizione indica su quale parametro si vuole applicare il guasto. Anche in questo caso il tool esegue un controllo finalizzato a stabilire la fattibilità del test; 3. tipo_iniezione specifica il tipo di guasto che s'intende applicare. In questo caso l'utente è chiamato a scegliere fra tre possibili alternative: 3.1 iniezione random prevede la modifica dell argomento target con un valore calcolato in maniera casuale; 70

71 3.2 iniezione con tecnica del bit flip effettua il complemento di un bit la cui posizione è indicata da parametro_iniezione; 3.3 iniezione user defined. In questo caso l'utente è chiamato a specificare anche il valore che si vuole sostituire a quello originariamente detenuto dall'argomento target; 4. parametro_iniezione assume un significato diverso a seconda del valore di tipo_iniezione (si rimanda al punto 3). A questo punto si possiedono informazioni sufficienti per adoperare il tool; infatti, volendo simulare l'alterazione del quinto bit dell'argomento numero uno dell'hypervisor_sched_op (numero 29), basterà richiamare lo script con i seguenti parametri: hypercall = 29 posizione = 1 tipo_iniezione = 1 (bit flip) parametro_iniezione = 5. E, avvalendosi delle caratteristiche native del tool l'utente può inoltre specificare: la probabilità con cui si verifica il guasto (un intero compreso tra 0 e 100); il numero di occorrenze del fault; l'intervallo temporale tra due guasti consecutivi. 71

72 Figura Esempio iniezione HYPERVISOR_sched_op Alle suddette caratteristiche sono state aggiunte altre in modo da consentire l'iniezione mirata di una specifica hypercall ampiamente trattata nel capitolo precedente: si tratta di HYPERVISOR_multicall. Questa hypercall si occupa di eseguire in batch un certo numero di hypercall raccolte in precedenza in un buffer. Quindi, a complemento dei parametri precedentemente illustrati, si aggiungono: mhypercall specifica la posizione dell'hypercall nel buffer a cui s'intende applicare il guasto; mposizione individua il campo dell'hypercall che s'intende iniettare. È possibile applicare il guasto al codice operativo, al valore di ritorno o ad uno dei sei parametri previsti; idhypercall individua l'hypercall che si vuole iniettare. Se a seguito di un controllo non dovesse risultare alcuna hypercall con detto id il guasto non avrà luogo. Lo scenario riportato in figura 3.6 illustra il caso in cui il fault viene iniettato nell argomento zero della hypercall numero tre 72

73 Figura Fault injection su HYPERVISOR_multicall 3.5 Raccolta dei risultati Terminata la fase di sperimentazione, l utente avrà a disposizione una raccolta di log, generati dal kernel della macchina testata e inviati al modulo controller tramite connessione UDP. A tal uopo, è anche possibile servirsi della porta seriale virtuale. 3.6 Dettagli implementativi In questo paragrafo si riporta una descrizione accurata dei vari moduli che 73

74 compongono il tool Modifiche al codice sorgente Si tratta di un patch da applicare al kernel che prevede la creazione del nuovo fault all avvio del sistema e l applicazione dello stesso in base alla configurazione fatta dall utente. Il tutto è stato ottenuto mediante la creazione di un nuovo file sorgente, initfault.c, e la modifica del file hypercall.h. La principale mansione di initfault.c è quella di inizializzare il guasto all avvio del sistema con parametri di default mediante la creazione di una directory nel file system virtuale in cui si configurano le caratteristiche del fault stesso. Tra le altre cose, initfault.c contiene funzioni da richiamare prima dell applicazione del fault atte a validare e ad impostare il guasto in linea con le scelte operate dall utente. In seguito è riportata l implementazione in linguaggio c della funzione should_fail_xen in cui è valutata la fattibilità del fault e in caso affermativo si procede con il set up del guasto che sarà successivamente iniettato. /* -1: non applico fault-injection 1: non applico fault-injection ma non chiamo la hypercall in questione 2: fault-injection - random (par1 = parametro da iniettare par2 = any) 3: fault-injection - bit flip (par1 = parametro da iniettare par2 = posizione bit all'interno del parametro) 4: fault-injection - user defined (par1 = parametro da iniettare par2 = valore da iniettare) */ 1 int should_fail_xen(int argomenti, int* par1, int* par2) 74

75 2 { 3 if (params.posizione < 0 params.posizione>argomenti) 4 return -1; 5 if (params.posizione==0) 6 return 1; 7 8 *par1=params.posizione; 9 *par2=params.parametro_iniezione; if (params.tipo_iniezione == 0) 12 return 2; //random 13 if (params.tipo_iniezione == 1) 14 return 3; //bit flip 15 if (params.tipo_iniezione == 2) 16 return 4; //user defined return -1; 19 } Figura Codice should_fail_xen Un caso particolare accade qualora s intende applicare il guasto alla funzione HYPERVISOR_multicall ampiamente descritta nei paragrafi precedenti. In questo scenario, infatti, prima dell applicazione del guasto è necessario completare il suo setup con dei parametri aggiuntivi. Tale compito è svolto dalla funzione get_other_params la cui implementazione in linguaggio C è riportata in seguito. Anche in questo caso l iniezione del fault è vincolata a determinate condizioni (riga 7). 75

76 1 int get_other_params(int* mpar1, int* mpar2, int *mpar3, 2 int nr_calls) 3 { 4 *mpar1 = params.mhypercall; 5 *mpar2 = params.mposizione; 6 *mpar3 = params.idhypercall; 7 return (params.mhypercall<= nr_calls && 8 params.mposizione<8); 9 } Figura Codice get_other_params Le altre modifiche hanno interessato il file hypercall.h (arch/x86/include/asm/xen/hypercall.h). È qui, infatti, presente l implementazione di ciascuna hypercall. Come descritto nel capitolo precedente, l esecuzione di una hypercall passa attraverso una funzione wrapper che si occupa di richiamare una delle macro apposite in linea con il numero di parametri previsti dalla funzione che s intende eseguire. Riassumendo è possibile schematizzare ciò che svolge una generica hypercall in tre punti come riportato in figura

77 HYPERVISOR_x (* parametri *) { 1. setup parametri 2. verifica hypercall da invocare 3. chiamata macro hypercall decisa al punto 1 } Figura Hypercall generica Per ciascuna di queste hypercall, sono state introdotte delle modifiche al codice in modo da supportare l iniezione del fault. Tali modifiche prevedono la sostituzione del blocco corrispondente al punto 1 di Figura 3.9 con un blocco che, nel complesso, si espleta nei seguenti punti: HYPERVISOR_x (* parametri *) { 1. setup parametri 1a. verifica condizioni applicazione fault 1b. setup fault 1c. applicazione fault 2. verifica hypercall da invocare 3. chiamata macro hypercall decisa al punto 1 } Figura Codice hypercall modificato 77

78 Dove l esecuzione dei punti 1b e 1c è vincolata all esito positivo del test del blocco 1a. Come caso concreto è riportato di seguito il codice c di una delle hypercall modificate. 1 static inline int 2 HYPERVISOR_multicall(void *call_list, int nr_calls) 3 { 4 int par1=0; //posizione parametro da iniettare 5 int par2=0; //dipende da par1 6 int mpar1=0; //posizione hypercall nel buffer da 7 //iniettare <= nr_calls 8 int mpar2=0; 9 int mpar3=0; 10 int res=0; 11 int found=0; 12 int inject = 0; 13 struct multicall_entry * m_entry; 14 if (hypercall_test(hypervisor_multicallnr) && 15 should_fail(&hfail_attr,1)) 16 { 17 res = should_fail_xen(2, &par1, &par2); 18 if (par1==1) //voglio iniettare il primo parametro 19 { 20 inject = get_other_params(&mpar1, &mpar2, 21 &mpar3, nr_calls); 22 } 23 } 24 //1: non invoco l'hypercall 25 if (res==1) 26 { 78

79 27 return; 28 } /*verifico se il parametro da iniettare è il nr o no. 32 mpar1 = 0 --> devo cercare l'hypercall mpar3 33 all'interno del buffer 34 mpar1 > 0 --> inietterà l'hypercall in posizione 35 mpar1 */ 36 if (mpar1==0) 37 { 38 int i =0; 39 while (i < nr_calls &&!found) 40 { 41 m_entry = call_list+ i * sizeof(struct 42 multicall_entry); 43 if (m_entry->op == mpar3) 44 found=1; 45 i++; 46 } } 49 else if (mpar1>0) 50 { 51 m_entry = call_list+ mpar1* sizeof(struct 52 multicall_entry); 53 found=1; 54 } if (res==2) /* 2: fault-injection - random (par1 = 58 pos. parametro da iniettare par2 =any, 59 non considerato in questo caso)*/ 60 { 79

80 61 62 if (inject && par1==1 && found==1) 63 { if (mpar2==0) //inietto op 66 { 67 get_random_bytes(&m_entry->op, 68 sizeof(unsigned long)); 69 } 70 if (mpar2==1) //inietto result 71 { 72 get_random_bytes(&m_entry->result, 73 sizeof(unsigned long)); 74 } 75 if (mpar2>1 && mpar2<8) //inietto 76 //uno dei sei argomenti 77 { 78 get_random_bytes(&m_entry->args[mpar2-2], 79 sizeof(unsigned long)); 80 } } 83 if (par1==2) 84 { 85 get_random_bytes(&nr_calls, sizeof(int)); 86 } 87 } 88 if(res==3) //3: fault-injection - bit flip (par1 = 89 //parametro da iniettare par2 = posizione 90 //bit all'interno del parametro) 91 { 92 if(inject && par1==1 && found==1) 93 { 94 if (mpar2==0) //inietto op 80

81 95 { 96 m_entry->op=flip(m_entry->op, par2); 97 } 98 if (mpar2==1) //inietto result 99 { m_entry->result=flip(m_entry->result, 102 par2); 103 } 104 if (mpar2>1 && mpar2<8) //inietto uno dei sei 105 //argomenti 106 { 107 m_entry->args[mpar2-2]=flip(m_entry-> 108 args[mpar2-2], par2); 109 } 110 } 111 if(par1==2) 112 { 113 nr_calls = flip(nr_calls, par2); 114 } 115 } if (res==4) //4: valore scelto dall'utente 118 { 119 if(inject && par1==1 && found==1) 120 { 121 if (mpar2==0) //inietto op 122 { 123 m_entry->op=par2; 124 } 125 if (mpar2==1) //inietto result 126 { 127 m_entry->result=par2; 128 } 81

82 129 if (mpar2>1 && mpar2<8) //inietto 130 //uno dei sei argomenti 131 { 132 m_entry->args[mpar2-2]=par2; 133 } 134 } 135 if(par1==2) 136 { 137 nr_calls = par2; 138 } } return _hypercall2(int, multicall, call_list, nr_calls); 143 } 144 Figura HYPERVISOR_multicall modificata Modulo per l iniezione dei guasti Sulla macchina target esegue un modulo, inject.sh, che si occupa di applicare il guasto inviato dal modulo xen_test.sh via ssh. Come evidenziato in figura 3.12, inject.sh scrive i parametri del guasto raccolti nel file system virtuale dal quale, una volta stabilita la fattibilità del guasto, saranno prelevati dalla funzione should_fail_xen. 82

83 Figura Schema iniezione fault Una configurazione alternativa prevede il lancio dello script inject.sh direttamente dalla macchina target. Tale configurazione, tuttavia, limita fortemente l usabilità del tool; infatti, in caso di crash della macchina, l utente dovrà predisporre il ravvio manualmente. Si riporta, in seguito, un piccolo estratto dallo script in questione. 1 if [[ $hypercall =~ ^[0-9]+$ ]] && [! -z "$hypercall" ]; 2 then 3 echo $hypercall > /sys/kernel/debug/hfail/hypercall 4 5 fi Figura Configurazione del parametro hypercall del guasto 83

84 Per ogni parametro ammesso, inject.sh, dopo aver testato che si tratta di un numero, lo pone nell apposita cartella del file system virtuale (istruzione 3) Iniettore DomU Lo script xen_test.sh gira nel dominio privilegiato; come più volte accennato, il suo compito è quello di prelevare dal file test.txt l ennesimo caso test e di inviarlo allo script inject.sh. È responsabile, inoltre, del monitoraggio dello stato della macchina target e della raccolta dei log generati dal kernel. #!/bin/bash #Funzionalità dello script: # 1. Monitora lo stato della macchina target predisponendo un riavvio nel caso di crash # 2. Avvia lo script di workload sul server Apache # 3. Legge i test da un file e li passa tramite ssh ad uno script di iniezione residente sulla macchina target # 4. Stampa a video un breve report del'iniezione in corso test=0 #contatore test notest=0 #indica se si effettua una test o meno in base ai parametri forniti in input multi=0 #1 se viene chiamata una HYPERVISOR_multicall par1=0 #1 se il paramentro oggetto del fault e par1 if [ "x$1" == "x" ] then echo "Usage: $0 {test file}" exit 1 fi #lancio per la prima volta il dominio che intendo testare state=`xm domstate Ubuntu1216` if [[ $state == "" ]] then echo "domain not active...need to start" xm create /etc/xen/ubuntu1216.cfg #echo "start Domanin Ubuntu " sleep 30; 84

85 else fi echo "domain already active..." #avvio workload server apache ssh -n -f 'cd httpref_fi;./work_gen.sh' >> httpref.txt while read line do if [[ ${line} == *,* ]] && [[! ${line} == //* ]]; then FILE="report/dmesg"$test".txt" ssh -n -f dmesg > $FILE sleep 5; if [[ -s $FILE ]] then echo "Target domain active..." else echo "Host unreachable...need to restart"; xm reset Ubuntu1216 echo "Restart Ubuntu 1216"; sleep 30; #avvio workload server apache ssh -n -f 'cd httpref_fi;./work_gen.sh' >> httpref.txt sleep 10; fi array #estraggo i parametri di un singolo test e li metto in un arr=$(echo ${line} tr "," "\n") index=0 for x in $arr do par[$index]=$x let "index += 1" done #applicazione test #h#l#i#a#m#n#t#p let "test += 1" echo applicazione test nr. $test echo "data "`date`" ("` date +%d_%m_%y_%h_%m_%s `")" case ${par[0]} in 13) echo "Iniezione HYPERVISOR_multicall" multi=1 ;; 29) echo HYPERVISOR_sched_op ;; 24) echo HYPERVISOR_vcpu_op ;; 32) echo HYPERVISOR_event_channel_op ;; 85

86 esac 0) echo HYPERVISOR_set_trap_table ;; *) echo No test notest=1 ${par[6]} ${par[4]} if [ "$notest" -eq 0 ] then case ${par[1]} in 0) echo non richiamo hypercall ;; 1) if [ "$multi" -eq 1 ] then echo "Oggetto iniezione: HYPERVISOR_multicall" if [ ${par[4]} -eq 0 ] then echo "Hypercall da iniettare nr: " else fi echo "Posizione Hypercall da iniettare: " ;; ;; $arg esac case ${par[5]} in 0) echo " --->Inietto il codice operativo" 1) echo " --->Inietto il valore di ritorno" *) let "arg=par[5]-2" echo " --->Inietto l'argomento: " esac fi ;; *) echo "Iniezione sul parametro" ${par[1]} if [ ${par[1]} -ne 0 ] then case ${par[2]} in 0) echo "Tipo iniezione: random" ;; 1) echo "Bit flip sul bit nr. " ${par[3]} ;; 2) echo "Iniezione user defined valore: " ${par[3]} esac fi echo "Probabilità fault: " ${par[8]} "%" echo "Numero di occorrenze fault: " ${par[7]} fi ssh -n -f /inject.sh -h ${par[0]} -l ${par[1]} -i ${par[2]} -a ${par[3]} -m ${par[4]} -n ${par[5]} -d ${par[6]} -t ${par[7]} -p ${par[8]} echo done... 86

87 notest=0 multi=0 par1=0 sleep 60; echo fi done < $1 echo echo fine Figura xen_test.sh 87

88 Capitolo 4 Sperimentazioni In questo capitolo sono presentati due possibili scenari di applicazione del tool. Nel primo caso, ci si servirà per valutare l'affidabilità di una certa macchina. Si tratta di una macchina con kernel Linux operante in ambiente virtualizzato in presenza di Xen hypervisor. Il secondo scenario prevede un'architettura più complessa rispetto al caso precedente: infatti, si avrà a che fare con due macchine virtuali di cui, una, sarà sottoposta agli stessi test previsti per il primo caso mentre dell'altra macchina si analizzeranno affidabilità e prestazioni allo scopo di valutare il grado di isolamento garantito dall'hypervisor Xen. 4.1 Profiling Il tool, prima dell avvio dell iniettore, offre la possibilità scegliere in maniera oculata le hypercall che saranno interessate, in seguito, dai guasti. Un possibile 88

89 criterio di scelta è di individuare le hypercall invocate con maggiore frequenza una volta sottoposto il dominio target a un certo workload. Tale workload consiste nell effettuare richieste http ripetute alla macchina in oggetto. Il tutto è ottenibile mediante lo script di profiling, profiler.sh, congiuntamente allo script per la generazione del workload work_gen.sh (per i dettagli si rimanda al capitolo precedente). Le hypercall invocate con maggiore frequenza sono: HPERCALL Frequenza HYPERVISOR_multicall 44.9% HYPERVISOR_sched_op 16.4% HYPERVISOR_vcpu_op 22.1% HYPERVISOR_event_channel_op 1.9% Figura 4.1 Frequenza di invocazione principali hypercall Una volta individuate le hypercall target è possibile procedere con la seconda fase. 89

90 4.2 Iniezione dei guasti La seconda fase, prevede l iniezione dei guasti alle hypercall individuate al passaggio precedente nonché la raccolta dei log generati dal sistema. Il primo scenario di test prevede due domini in esecuzione: 1. Il primo, il Dom0, è un dominio con sistema operativo Ubuntu (kernel 3.2.0) su cui esegue lo script che si occupa del controllo della campagna di testing; 2. Un secondo dominio, DomU, rappresenta la macchina da testare. Come accennato nell introduzione, il ruolo del Dom0 è monitorare lo stato di avanzamento dei test nonché le condizioni della macchina target (crash, hang). Queste mansioni sono svolte da un unico modulo, xen_test.sh. Per poter meglio comprendere le funzionalità di tale modulo è di seguito riportata la sequenza di passi necessaria per l applicazione di un singolo caso di test: 1. Per prima cosa, la macchina target deve essere avviata; tale compito è eseguito attraverso il comando: xm create /etc/xen/ubuntu1216.cfg dove Ubuntu1216 è il nome della macchina che sarà sottoposta ai test nelle fasi successive; 2. Completato l avvio della macchina target, lo script prevede l avvio del web server Apache sul domu. Il tutto avviene, tramite connessione ssh attraverso il comando: 90

91 ssh -n -f $HOST `service apache2 restart` dove HOST indica l indirizzo ip della macchina target; Figura 4.2 Avvio server web Apache 3. A questo punto, è possibile avviare un workload allo scopo di simulare condizioni reali di funzionamento del DomU. Detto workload, consiste nel generare continue richieste http al web server Apache. L output di questo script viene salvato su un file, httperf.txt e costituirà uno dei report utili nella fase di analisi dei risultati; 91

92 Figura 4.3 Avvio workload 4. La quarta fase consiste nell iniezione del test i-esimo, prelevato da un file test.txt che contiene la lista dei test che s intende condurre. Tale test viene inviato tramite connessione ssh ad uno script sul domu, inject.sh, che provvede all iniezione vera e propria. Il tutto avviene mediante il comando: ssh -n -f $HOST./inject.sh -h ${par[0]} -l ${par[1]} -i ${par[2]} -a ${par[3]} -m ${par[4]} -n ${par[5]} -d ${par[6]} -t ${par[7]} -p ${par[8]} 92

93 Figura 4.4 Iniezione guasto 5. Contestualmente alla fase di iniezione, viene avviata anche una fase di raccolta dei log generati dal kernel della macchina target. Tali log sono inviati al Dom0 tramite connessione UDP, dal modulo netconsole che esegue sul domu. Nel Dom0 uno script si mette in ascolto e trasferisce su un file, test_xen.txt, tutto quello che riceve dal suddetto porto. 93

94 Figura 4.4 Acquisizione log Le fasi appena citate, vanno ripetute per ciascun test. Inoltre al termine di ogni test, viene effettuato un controllo dello stato della macchina target, predisponendo un riavvio in caso di anomalie. 4.3 Scelta delle hypercall I casi di test considerati in questo primo scenario hanno interessato un unica hypercall: hypervisor_multicall. I motivi che hanno portato a tale scelta sono due: 1. L hypercall in questione risulta, a valle della fase di profiling, tra quelle maggiormente invocate; 94

95 2. Come riportato nei capitoli precedenti, tra le tante hypercall, hypervisor_multicall è da considerarsi particolare, poiché una sua invocazione consente di eseguire in batch più hypercall. Sono stati individuati 50 casi di test, ciascuno dei quali ripetuto 8 volte. Il tutto è stato eseguito in 11 ore circa. 4.4 Raccolta dei risultati In questo paragrafo si illustrano strategie di raccolta dei risultati applicate a ciascuno dei due test previsti Risultati esperimento uno A conclusione di ogni test il tool genera i seguenti file, che saranno esaminati nell'ultima fase di analisi dei risultati. Tali file sono: 1. xen_test.txt contiene la descrizione di ciascun test iniettato e i log generati dal kernel a seguito della sua applicazione. Esistono casi in cui l'applicazione di un test non ha prodotto alcun log; le motivazioni possibili sono due e concettualmente opposte: - il test non ha provocato il fallimento dell'hypercall interessata. Ad esempio, nel caso dell'hypervisor_multicall la corruzione di un'area di memoria, all'interno del buffer multicall_entry, non utilizzata nell'esecuzione corrente non ha alcun effetto; 95

96 - il test provoca un crash immediato del sistema. Questa condizione inibisce il modulo netconsole di compiere il proprio lavoro. È proposto in figura, lo stralcio del file in questione in cui è riportata una descrizione dettagliata del test, un timestamp (utile nelle analisi successive) e i log raccolti a seguito della sua applicazione: Target domain active... applicazione test nr. 2 data dom 17 feb 2013, , CET (17_02_2013_20_00_10) Iniezione HYPERVISOR_multicall Oggetto iniezione: HYPERVISOR_multicall Hypercall da iniettare nr: 3 --->Inietto il codice operativo Bit flip sul bit nr. 4 Probabilità fault: 100 % Numero di occorrenze fault: 4 done... kernel logs test 2 [ ] 1 multicall(s) failed: cpu 0 [ ] 1 multicall(s) failed: cpu 0 [ ] 1 multicall(s) failed: cpu 0 [ ] 1 multicall(s) failed: cpu 0 Figura 4.4 Spaccato file test_xen.txt 96

97 2. httperf.txt contiene l'output prodotto dall'esecuzione di httperf. Le informazioni in questo file sono utili sia per verificare l'esito di ciascuna richiesta http, sia per eseguire un'analisi prestazionale. Infatti, al termine di ciascuna sequenza di richieste (se ne eseguono 50 alla volta), vengono generati dei report utili per le analisi successive. Al termine della campagna d iniezione, uno script, dimensione_httperf.sh, genera in output, per ogni test, la dimensione del file httperf.txt associata. Questa informazione, può essere utile a discriminare casi di test che hanno prodotto anomalie a livello applicativo da quelli innocui. Infatti, un test che ha arrecato danni a livello applicativo, può comportare un rallentamento dei tempi di risposta delle richieste http e quindi un throughput inferiore rispetto ai casi nominali. 3. access.log e error.log. Se il test i-esimo si conclude senza un crash o riavvio forzato della macchina è prevista la raccolta dei log prodotti da Apache nel periodo di applicazione del suddetto test. Queste informazioni, congiuntamente a quelle riportate in httperf.txt, consentono di valutare l'esito di ciascuna richiesta effettuata al server Apache. 97

98 Panoramica Prima di procedere con la descrizione dei risultati si danno alcuni cenni circa i criteri di classificazione stabiliti. A valle dell'applicazione di ciascun guasto si può verificare una delle seguenti condizioni: 1. crash; 2. restart; 3. hang; 4. workload failure; Crash Si tratta di uno scenario in cui il dominio si riavvia automaticamente a seguito dell'iniezione. Tale condizione è rilevata nei log prodotti da Xen e ricondotta allo specifico test responsabile mediante una procedura manuale; infatti, nei log prodotti da Xen l'informazione relativa al crash di un dominio è associata ad un timestamp. [ :37: ] WARNING (XendDomainInfo:2061) Domain has crashed: name=ubuntu1214p id=12 Figura 4.6 Messaggio contenuto nel log di Xen relativo ad un crash di un dominio 98

99 Target domain active... applicazione test nr. 39 data dom 17 feb 2013, , CET (17_02_2013_20_37_29) Iniezione HYPERVISOR_multicall Iniezione sul parametro 2 Bit flip sul bit nr. 10 Probabilità fault: 100 % Numero di occorrenze fault: 1 done... kernel logs test 39 Figura 4.7 Guasto responsabile del crash di Figura 4.6 Una volta rinvenuta l'informazione temporale è possibile trovare la corrispondenza con il guasto responsabile esplorando il file test_xen.txt nel quale ogni test reca nella sua descrizione il timestamp. Come già accennato, si tratta di uno scenario in cui non è disponibile alcun log prodotto dal kernel, proprio perché il crash del sistema impedisce al modulo netconsole di trasferire tali log al Dom0. In Figura 4.7 è riportata la descrizione del guasto che ha causato il crash del dominio (Figura 4.6). In questo caso, il crash del sistema era atteso dato che il guasto altera un bit di un puntatore che, da questo momento in poi, si riferisce ad un'area di memoria eventualmente non accessibile. Si noti, che l'applicazione della stessa tipologia di guasto a un bit meno significativo (ad esempio il primo), tipicamente, non sfocia nella conseguenza appena descritta; è stato verificato, infatti, in presenza di questo tipo di guasto, che il sistema continua la propria 99

100 esecuzione senza comportamenti anomali. È probabile, tuttavia, che tali anomalie possano interessare il livello applicativo Restart In questo scenario, il dominio, a seguito dell'applicazione del guasto, necessita di un riavvio forzato. Questa condizione è rilevata dallo script di iniezione, xen_test.sh, che si occupa di registrarla nei file log preposti (xen_test.txt). In particolare, lo script xen_test.sh, prima di applicare un dato fault, valuta le condizioni della macchina; in tal proposito, affinché si possa proseguire con i test senza riavviare la macchina target devono essere verificate due condizioni: per prima cosa si verifica se è possibile raggiungere il dominio tramite ping, in caso di esito positivo il secondo test di raggiungibilità prevede l'accesso alla macchina tramite connessione ssh. Se l'esito di uno dei due test proposti non dovesse rivelarsi positivo, il tool predispone il riavvio della macchina notificando il tutto nei log. Nel caso di irraggiungibilità, si procede col riavvio della macchina. Terminata la campagna di iniezione, uno script, parse_log.sh, consente di individuare i casi di test che hanno provocato un restart analizzando i log del kernel. In Figura 4.8 è riportato quanto raccolto dal tool nel caso di condizione di restart. Oltre alla descrizione del tipo di guasto, si riportano successivamente i log generati dal kernel offrendo all'utente la possibilità di venire a conoscenza delle motivazioni che hanno portato a tale condizione. 100

101 Target domain active... applicazione test nr. 43 data dom 17 feb 2013, , CET (17_02_2013_20_40_44) Iniezione HYPERVISOR_multicall Iniezione sul parametro 2 Tipo iniezione: random Probabilità fault: 100 % Numero di occorrenze fault: 4 done... kernel logs test 43 [ ] [ cut here ] [ ] kernel BUG at arch/x86/xen/multicalls.c:94! [ ] invalid opcode: 0000 [#4] SMP [ ] Modules linked in: netconsole [ ] [ ] Pid: 1042, comm: inject.sh Tainted: G D #19 [ ] EIP: 0061:[<c >] EFLAGS: CPU: 0 [ ] EIP is at xen_mc_flush+0x1a7/0x1c0 [ ] EAX: fffffff2 EBX: ec7ef100 ECX: 4b6249f0 EDX: [ ] ESI: ec7ef10c EDI: ec EBP: c2329e88 ESP: c2329e48 [ ] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [ ] Process inject.sh (pid: 1042, ti=c task=c21a8ca0 task.ti=c ) [ ] Stack: [ ] c2329e94 c eb7de000 c c ff ec

102 [ ] c ec c2329e94 c1006c44 eb7de000 c2329eac [ ] c c c c c2329eb4 c c2329ec4 [ ] Call Trace: [ ] [<c >]? xen_pgd_walk+0x144/0x170 [ ] [<c >]? xen_do_pin+0x30/0x30 [ ] [<c1006c44>] xen_mc_issue+0x34/0x40 [ ] [<c >] xen_pgd_unpin+0x79/0x90 [ ] [<c >] xen_pgd_unpin+0x10/0x20 [ ] [<c >] xen_exit_mmap+0x34/0x40 [ ] [<c113a10d>] arch_exit_mmap+0xd/0x10 [ ] [<c113c34f>] exit_mmap+0x2f/0xd0 [ ] [<c1010e7a>]? spin_time_accum_total+0x2a/0x40 [ ] [<c1010f1b>]? xen_spin_lock+0x7b/0xb0 [ ] [<c11b34d3>]? exit_aio+0x63/0xa0 [ ] [<c104bd64>]? test_ti_thread_flag+0x14/0x20 [ ] [<c104bde7>]? need_resched+0x17/0x30 [ ] [<c1062a9f>] mmput+0x4f/0xb0 [ ] [<c10690be>] exit_mm+0xde/0xf0 [ ] [<c10691c4>] do_exit+0xf4/0x300 [ ] [<c116d1dc>]? vfs_read+0xac/0xe0 [ ] [<c116c640>]? do_sync_write+0xe0/0xe0 [ ] [<c >] do_group_exit+0x42/0x90 [ ] [<c >] sys_exit_group+0x18/0x20 [ ] [<c164e7d4>] syscall_call+0x7/0xb [ ] Code: 4b 18 8b b 43 0c b b 73 1c e8 46 fb ff ff 89 c c1 ef 1f e9 9b fe ff ff <0f> 0b ba b8 b9 f0 83 c1 e8 28 ec e9 d1 fe ff [ ] EIP: [<c >] xen_mc_flush+0x1a7/0x1c0 SS:ESP 0069:c2329e48 102

103 [ ] ---[ end trace 74842dbe10b010c2 ]--- [ ] Fixing recursive fault but reboot is needed! [ ] FAULT_INJECTION: forcing a failure [ ] Pid: 1042, comm: inject.sh Tainted: G D #19 [ ] Call Trace: [ ] [<c1319d0d>]? fail_dump+0x2d/0x40 [ ] [<c1319fbb>]? should_fail+0xbb/0xf0 [ ] [<c >]? HYPERVISOR_multicall+0x197/0x2e0 [ ] [<c100aa64>]? get_phys_to_machine+0x34/0x80 [ ] [<c100484d>]? xen_mc_flush+0xbd/0x1c0 [ ] [<c10093b8>]? xen_force_evtchn_callback+0x8/0x10 [ ] [<c1009e10>]? check_events+0x8/0xc [ ] [<c1009e07>]? xen_restore_fl_direct_reloc+0x4/0x4 [ ] [<c10036e9>]? arch_local_irq_restore+0x9/0x10 [ ] [<c >]? xen_end_context_switch+0x10/0x20 [ ] [<c10112ad>]? arch_end_context_switch+0xd/0x10 [ ] [<c10119dd>]? switch_to+0x9d/0x110 [ ] [<c104327d>]? context_switch.isra.109+0x8d/0xf0 [ ] [<c104a3b7>]? pick_next_task_idle+0x17/0x20 [ ] [<c164cf47>]? schedule+0x97/0x1a0 [ ] [<c164d208>]? schedule+0x18/0x20 [ ] [<c106bded>]? run_ksoftirqd+0xfd/0x140 [ ] [<c1086b94>]? kthread+0x64/0x70 [ ] [<c106bcf0>]? do_softirq+0x120/0x120 [ ] [<c1086b30>]? create_kthread+0x40/0x40 [ ] [<c1644e7e>]? kernel_thread_helper+0x6/0x10 [ ] [ cut here ]

104 [ ] kernel BUG at arch/x86/xen/multicalls.c:94! [ ] invalid opcode: 0000 [#4] SMP [ ] Modules linked in: netconsole [ ] [ ] Pid: 1042, comm: inject.sh Tainted: G D #19 [ ] EIP: 0061:[<c >] EFLAGS: CPU: 0 [ ] EIP is at xen_mc_flush+0x1a7/0x1c0 [ ] EAX: fffffff2 EBX: ec7ef100 ECX: 1e46987e EDX: [ ] ESI: ec7ef10c EDI: c21a8ca0 EBP: ebcbff08 ESP: ebcbfed8 [ ] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [ ] Process inject.sh (pid: 1042, ti=ebcbe000 task=c21a8ca0 task.ti=c ) [ ] Stack: [ ] c10093b8 ebcbfef8 c1009e c1009e07 c10036e9 [ ] ebcb0040 ebcb1940 ec7f3f00 c21a8ca0 ebcbff14 c ebcb1940 ebcbff1c [ ] c10112ad ebcbff3c c10119dd 00cb ebcb1c40 16c [ ] Call Trace: [ ] [<c10093b8>]? xen_force_evtchn_callback+0x8/0x10 [ ] [<c1009e10>]? check_events+0x8/0xc [ ] [<c1009e07>]? xen_restore_fl_direct_reloc+0x4/0x4 [ ] [<c10036e9>]? arch_local_irq_restore+0x9/0x10 [ ] [<c >] xen_end_context_switch+0x10/0x20 [ ] [<c10112ad>] arch_end_context_switch+0xd/0x10 [ ] [<c10119dd>] switch_to+0x9d/0x110 [ ] [<c104327d>] context_switch.isra.109+0x8d/0xf0 [ ] [<c104a3b7>]? pick_next_task_idle+0x17/0x20 [ ] [<c164cf47>]? schedule+0x97/0x1a0 [ ] [<c164d208>]? schedule+0x18/0x20 104

105 [ ] [<c106bded>]? run_ksoftirqd+0xfd/0x140 [ ] [<c1086b94>]? kthread+0x64/0x70 [ ] [<c106bcf0>]? do_softirq+0x120/0x120 [ ] [<c1086b30>]? create_kthread+0x40/0x40 [ ] [<c1644e7e>]? kernel_thread_helper+0x6/0x10 [ ] Code: 4b 18 8b b 43 0c b b 73 1c e8 46 fb ff ff 89 c c1 ef 1f e9 9b fe ff ff <0f> 0b ba b8 b9 f0 83 c1 e8 28 ec e9 d1 fe ff [ ] EIP: [<c >] xen_mc_flush+0x1a7/0x1c0 SS:ESP 0069:ebcbfed8 [ ] ---[ end trace 74842dbe10b010c3 ]--- [ ] Fixing recursive fault but reboot is needed! Host unreachable...need to restart Figura 4.8 Restart del dominio Hang In questo scenario la macchina target è ancora attiva ma non risulta raggiungibile dalla connessione ssh. Questa condizione è rilevabile facilmente dal momento che lo script di iniezione non riesce a continuare con le operazioni successive a causa del crash del server ssh sulla macchina target. Si tratta di un caso speciale di restart, separato in base alle sue caratteristiche. In questo caso, un rivelatore di soft lockup ha notato che la CPU non è più utilizzabile da alcun processo. 105

106 [ ] BUG: soft lockup - CPU#0 stuck for 22s! [rs:main Q:Reg:326] Figura 4.9 Messaggio di soft lockup esibito dal kernel in caso di hang Workload Failure Questo scenario è meno critico di quelli discussi prima. Infatti, il sistema operativo ha continuato la propria esecuzione senza problemi. Tuttavia si riscontrano delle anomalie a livello applicativo. È possibile fare una distinzione di tali anomalie suddividendole in quattro categorie: - Errori interni di Apache: tali situazioni sono riportate nel file error.log di Apache. Nei test condotti, non è stata rinvenuta alcuna anomalia di questo tipo; - Fallimenti http: si tratta di casi in cui una richiesta http non è andata in porto a causa del guasto iniettato; tali informazioni sono ottenibili attraverso l'analisi congiunta dei file httperf.txt e access.log; in particolare, al termine della sequenza di richieste http generate da httperf, è prodotto un report in cui è possibile conoscere: o la media delle richieste andate in porto; o la media dei tempi di risposta. 106

107 Queste informazioni sono sufficienti a provare casi di anomalie a livello applicativo (ad esempio 404/Not Found). La raccolta di tali informazioni avviene attraverso uno script che verifca se nel file httperf.txt relativo al test i-esimo esistono richieste non terminate con successo (2xx). L output prodotto dallo script consiste nella lista di test che hanno provocato almeno un fallimento tra le richieste http previste durante una singola iniezione. - Timeout http: in questo caso l'occorrenza di uno o più guasti ha provocato l'aumento dei tempi risposta delle singole richieste http. Al termine dell iniezione risulta che il numero di richieste http servite è minore rispetto a quelle portate a termine in un esecuzione tipica; anche in questo caso, dette informazioni, sono deducibili dai file httperf.txt e access.log; - Errori di connessione: si tratta di uno scenario in cui a seguito dell'applicazione del guasto l'host risulta irraggiungibile e quindi non è possibile servire alcuna richiesta http. 107

108 Analisi dei risultati L'applicazione dei test ha prodotto i risultati riassunti nelle seguenti tabelle: Tipo fallimento # occorrenze % Crash 10 2,4 Restart ,4 Hang 13 3,24 Workload failure 64 16,0 Tabella 4.1 Risultati 1 Dove la voce workload failure contempla i fallimenti di Apache nelle situazioni in cui non è si è verificato alcun fallimento del sistema operativo (crash, restart, hang). Questo risultato è stato ottenuto attraverso altri script di parsing. Per quanto riguarda i fallimenti totali di Apache la seguente tabella riassume i risultati ottenuti. Tipo fallimento # occorrenze % Errori interni di Apache 0 0 Fallimenti http Omissioni http ,5 Errori di connessione ,25 Tabella 4.2 Failure a livello applicativo 108

109 Anche in questo caso, occorrenze indica il numero dei test che hanno provocato almeno uno fallimento di quelli riportati in Tabella 4.2. Inoltre, tali valori non sono da considerarsi esclusivi. Infatti, una condizione di restart del sistema comporta: 1. Fallimenti di richieste http: le ultime richieste giunte prima del restart possono non essere servite correttamente; 2. Omissioni di richieste: le ultime richieste giunte prima del restart possono non essere affatto servite; o ancora, una condizione di hang, ha il seguente effetto collaterale: 3. Richieste generate non raggiungeranno mai il server Failure % Failure Crash Hang Restart Workload Failure Figura 4.10 Grafico failure provocati dal test 109

110 Sulla base dei risultati rivenuti si può concludere che Xen presenta un buon grado di robustezza dato che in nessuno caso l'hypervisor è andato in crash. Anche per le macchine virtuali non sono state individuate situazioni anomale, infatti il fault rimane circoscritto alla macchina in cui si è manifestato Risultati esperimento 2 L'esperimento due propone di valutare il grado di isolamento temporale e spaziale messo in atto da Xen. Figura Scenario di test numero due 110

111 Panoramica La Figura 4.11 ha il solo scopo di rendere l dea sullo scenario previsto dall esperimento, dato che l approccio utilizzato è, per molti aspetti, simile all esperimento uno, ampiamente discusso nei paragrafi precedenti. In questo caso le macchine virtuali previste sono due, nella fattispecie si tratta ancora di macchine con sistema operativo Ubuntu (kernel 3.2.0). Come accennato nell introduzione, lo scopo di questa campagna di test è valutare il grado di isolamento offerto da Xen. In particolare si vuole sottoporre la macchina A agli stessi test previsti nella campagna precedente valutando come le conseguenze dei test possano incidere sull altra macchina, B, sulla quale è in esecuzione lo stesso workload previsto per A. Anche in questo caso il workload consiste nel sottoporre i due domini a sequenze di richieste http. Poiché si è interessati al comportamento della macchina B, è stato necessario modificare lo script di iniezione xen_test.sh in modo da: - Eseguire il workload previsto (che è lo stesso di A); - Raccogliere i log prodotti dal kernel e da Apache Analisi puntuale Al termine della campagna di sperimentazione l analisi dei risultati consiste, principalmente, nello studio dei log prodotti dal kernel della macchina B e del file httperf.txt generato dal singolo test. Entrambi i tipi di informazione sono stati raccolti nelle medesime modalità previste dal test numero uno. 111

112 Come auspicato, analizzando i log del kernel non è stata rinvenuta alcuna informazione anomala; questo conferma, dal punto di vista dell affidabilità, quanto si riporta più volte in letteratura riguardo la virtualizzazione che garantisce un isolamento totale tra le varie macchine, rivelandosi come una soluzione sicura e affidabile rispetto ad approccio non virtualizzato. Per quel che riguarda i file httperf.txt, il loro studio è finalizzato alla valutazione delle prestazioni. Al termine di ciascuna sequenza di richieste http generate (si ricorda che sono previste 50 richieste per volta), il modulo httperf fornisce delle statistiche sia prestazionali sia inerenti l esito della sequenza di richieste. In questo caso l attenzione è puntata sul valore medio del tempo di risposta prodotto al termine di ciascuna sequenza di richieste. Tale parametro è confrontato con quello ottenibile in uno scenario di esecuzione privo di guasti. In particolare: 1. Nella prima fase della presente sperimentazione entrambi i domini sono sottoposti a sequenze di richieste http per un certo quanto temporale; al termine, si avranno in output, i valori medi dei tempi di risposta di ciascuna sequenza di richieste per ciascun dominio; 2. Si procede allo stesso modo previsto nel punto 1, con la differenza che uno dei domini (A) sarà sottoposto anche all iniezione dei guasti discussa all inizio del paragrafo. Terminate le due fasi, con l ausilio di alcuni script di parsing, applicati ai file httperf.txt generati, si avrà in output: 1. La lista dei tempi medi di risposta della macchina A in assenza di test; 112

113 2. La lista dei tempi medi di risposta della macchina B in assenza di test; 3. La lista dei tempi medi di risposta della macchina A su cui sono applicati i test; 4. La lista dei tempi medi di risposta della macchina B avendo applicato i guasti su A Analisi delle prestazioni Nel grafico di figura 4.12 è proposto un confronto tra i tempi medi di risposta della macchina A di figura Nella fattispecie: - La curva rossa indica l andamento della media dei tempi di risposta della macchina sottoposta ai test; - La curva blu indica, invece, l andamento della media dei tempi di riposta della stessa macchina senza l applicazione dei test. Come auspicabile è evidente che l iniezione dei guasti comporta un degradamento delle prestazioni rispetto ad un caso di riferimento (curva blu). 113

114 % esperimenti Un infrastruttura di robustness testing per sistemi virtualizzati in ambiente Xen VM Senza fault VM con fault 20 0 Avg reply rate (ms) Figura 4.12 Grafico tempi medi di riposta macchina A Nel grafico di figura 4.13 è proposto un confronto tra i tempi medi di risposta della macchina B di figura Come accennato in precedenza in nessuno dei due casi la suddetta macchina è stata oggetto dei test; in questa sede si vuole valutare il suo comportamento quando vengono iniettati i guasti ad un altra macchina presente nell infrastruttura (A). Nella fattispecie: - La curva rossa indica l andamento della media dei tempi di risposta della macchina applicando i test su A - La curva blu indica, invece, l andamento della media dei tempi di riposta della stessa macchina senza l applicazione dei test. 114

115 AVG reply rate (ms) Figura 4.13 Grafico tempi medi di riposta macchina B Come si evince dal grafico, applicando i test alla macchina A, l andamento dei tempi medi di risposta si distribuisce in maniera diversa dalla distribuzione di riferimento (curva rossa). È stato calcolato che la media dei tempi di risposta aumenta di circa dell 11% rispetto ad un caso di assenza di guasti, per cui, è possibile concludere che un malfunzionamento di una macchina virtuale può inficiare, anche significativamente, sulle prestazioni delle altre macchine esistenti. 115

116 Bibliografia [1] D. Lardner Babbage's calculating engine [2] C. Babbage On the mathematical powers of the calculating engine [3] Proceedings of the Joint AIEE-IRE Computer Conference [4] Information processing systems - reliability and requirements [5] Diagnostic programs and marginal checking for large scale digital computers [6] J. von Neumann Probabilistic logics and the synthesis of reliable organisms from unreliable components [7] E.F. Moore and C.E. Shannon Reliable circuits using less reliable relays [8] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell. Fundamental Concepts of Dependability. [9] J. Durães and H. Madeira Emulation of Software faults: A Field Data Study and a Practical Approach [10] Kao, W., Iyer, R DEFINE: A Distributed Fault Injection and Monitoring Environment 116

117 [11] Philip Koopman, John DeVale. The Exception Handling Effectiveness of POSIX Operating Systems [12] Stefan Winter Choosing Error Models for OS Robustness Evaluations [13] J.K. Chaar et al. R. Chillarege, I.S. Bhandari Orthogonal defect classification-a concept for in-process measurements 117