Architetture per l implementazione di macchine virtuali

Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Calcolatori Elettronici I Architetture per l implementazione di macchine virtuali Anno Accademico 2017/18 Candidato: Francesco Giuseppe Caccavale Matr. N46002567

Alle vittime innocenti della Terra Dei Fuochi Alla mia Famiglia

Indice Indice... III Introduzione... 1 Capitolo 1: Virtualizzazione... 2 1.1 Virtualizzazione CPU... 5 1.2 Tecnologie di Virtualizzazione Intel... 11 1.2.1 Architettura VT-x... 12 1.2.2 Architettura VT-i... 15 1.2.3 Classificazione delle primitive Intel... 17 1.3 Virtualizzazione sull Architettura ARM... 18 1.4 Virtualizzazione della Memoria... 20 1.5 Virtualizzazione dell I/O... 23 Capitolo 2: Le Architetture VMware e Xen... 27 2.1 L hypervisor VMware Workstation... 27 2.1.1 Gestione della Memoria... 30 2.1.2 Gestione dell I/O... 31 2.2 L hypervisor Xen... 32 2.2.1 Gestione della Memoria... 34 2.2.2 Gestione dell I/O... 35 Conclusioni... 36 Bibliografia... 37 III

Introduzione Lo scopo dell elaborato è illustrare le problematiche e i vantaggi della virtualizzazione, le diverse tecniche per implementarla sulle architetture Intel e ARM e infine presentare due casi di studio di tale tecnologia. La struttura dell elaborato è la seguente: nel capitolo 1 viene introdotto il concetto di Macchina virtuale, le motivazioni del suo impiego e i suoi benefici. Inoltre vengono presentate le tecniche per la virtualizzazione della CPU (in particolare dell approccio adottato da Intel e ARM), della memoria e dell I/O. Nel capitolo 2 vengono presentate due implementazioni della virtualizzazione: gli hypervisor VMware e Xen. In particolare, viene brevemente delineata la storia dei due hypervisor, e in seguito vengono descritte le modalità e i procedimenti usati nei due VMM per la realizzazione della virtualizzazione. Nelle conclusioni vengono presentati gli sviluppi futuri della virtualizzazione, nello specifico vengono mostrate delle statistiche sui vantaggi economici e ambientali derivanti dal suo utilizzo e sulle conseguenze del suo impiego. 1

Capitolo 1: Virtualizzazione La virtualizzazione è l emulazione software di uno o più componenti hardware (CPU,memoria,etc.) su una singola macchina fisica, allo scopo di migliorare la condivisione, l utilizzo delle risorse e le prestazioni. Un tipico esempio in cui l impiego di questa tecnica può essere conveniente è il caso di una società informatica che possiede un server email, un web serverr, un FTP server e un DBMS. Tutte queste applicazioni vengono eseguite su diversi computer, e sono collegate da una rete ad alta velocità. Il problema di tale società è che, nonostante il sistema multicomputer sia affidabile, sicuro e flessibile, i costi sono alti e ci sono delle difficoltà a gestire tutte le macchine. Inoltre la percentuale di utilizzo medio della CPU del sistema si aggira intorno al 10%, e ciò si traduce in una scarsa efficienza ed elevati costi.[1] Fig 1.1: Performance Cpu senza Virtualizzazione Per risolvere il problema di cui sopra si ricorre alla virtualizzazione. L idea è quella di porre i diversi server sulla stessa piattaforma hardware(workload migration). Per fare ciò viene introdotta un astrazione, ossia la Macchina Virtuale(VM), la quale è una simulazione software di una macchina fisica reale e fornisce un ambiente operativo virtuale. Su ogni Macchina Virtuale viene eseguito un sistema operativo e delle 2

applicazioni. La Macchina Virtuale e le risorse sono gestite dal VMM, Virtual Machine Monitor o hypervisor. I vantaggi della virtualizzazione sono molteplici. Il primo vantaggio è sicuramente un uso più efficiente delle risorse, infatti con essa la percentuale di utilizzo medio delle CPU si aggira attorno al 75% %, e quindi vi è una riduzione dei costi (Efficienza). Fig.1.2 Performance Cpu con Virtualizzazione Il secondo vantaggio è che il fallimento di una macchina virtuale non ha effetti sulle altre VM (Isolamento). Altri vantaggi sono legati alla Sicurezza, in quanto una eventuale intrusione riguarderebbee la singola VM e non l intero sistema, e inoltre applicazioni legacy, cioè obsolete, possono essere eseguite sulla stessa macchina di applicazioni più moderne (Flessibilità). Un ulteriore vantaggio è costituito dal cosiddetto cloud computing e riguarda la possibilità per l utente di utilizzare, dietro pagamento, servizi offerti da terzi senza doversi preoccupare della manutenzione e della gestione delle macchine fisiche( servizio pay per use). Infine, per uno sviluppatore di applicazioni che devono essere eseguite su diversi ambienti, risulta più facile il testing in quanto, anzichè effettuare tanti partizionamenti della memoria di massa, può installare sul proprio device tante VM quanti 3

sono i Sistemi Operativi su cui la sua app deve operare. Detto ciò, il VMM e il sistema operativo hanno entrambi l obiettivo di gestire le risorse hardware, la differenza tra i due sta nel fatto che il SO le gestisce per conto di thread e processi, mentre il VMM le gestisce per conto di Macchine Virtuali ed SO. Entrambi utilizzano tecniche di memoria virtuale, entrambi utilizzano il disco, ma il sistema operativo lo organizza in file e directory, mentre l hypervisor lo virtualizza. Infine, mentre il SO utilizza delle Socket o dei canali di comunicazione, l hypervisor usa una rete virtuale. Esistono due tipi di architetture per la virtualizzazione. Nella prima l hypervisor esegue direttamente sull hardware(bare metal virtualization ), nella seconda l hypervisor viene eseguito su un sistema operativo tradizionale(hosted hypervisor). La prima viene generalmente usata in ambito server e garantisce prestazioni migliori, mentre la seconda soluzione viene adottata in ambito desktop (Es. Oracle Virtual Box). I sistemi operativi eseguiti al di sopra della VM vengono chiamati guest OS, mentre nel secondo approccio il sistema operativo che ospita l hypervisor viene chiamato host OS. Fig.1.3 Hypervisor di tipo 1 (bare-metal virtualization) 4

Fig 1.4 Hypervisor di tipo 2 (hosted hypervisor) I requisiti per la realizzazione della virtualizzazione sono stati definiti da Popek e Goldberg[3]. Il primo requisito è un ambiente di esecuzione per i programmi sostanzialmente identico a quello della macchina reale. Il secondo è quello di garantire un elevata efficienza nell esecuzione dei programmi. Quando possibile, il VMM deve permettere l esecuzione diretta delle istruzioni impartite dalle macchine virtuali: le istruzioni non privilegiate vengono eseguite direttamente in hardware senza coinvolgere il VMM. Infine bisogna garantire la stabilità e la sicurezza dell intero sistema. Il VMM deve rimanere sempre nel pieno controllo delle risorse hardware: i programmi in esecuzione nelle macchine virtuali (applicazioni e S.O.) non possono accedere all hardware in modo privilegiato. 1.1 Virtualizzazione CPU Il primo problema da affrontare riguarda la coesistenza dei guest OS e dell hypervisor. Questo problema sorge perché il sistema operativo viene sviluppato in modo da avere accesso esclusivo e privilegiato allo stato del processore, alle eccezioni che possono essere sollevate, agli interrupt, alla tabella delle pagine, alle porte I/O. In altri termini il SO esegue istruzioni sensibili, ossia istruzioni che interagiscono con l hardware, come gestione dei registri di I/O, interrupt etc., e istruzioni privilegiate, ossia istruzioni che 5

generano una trap se eseguite all interno dell user mode.[3] Il VMM deve fornire al sistema operativo una simulazione di tali meccanismi, in quanto adesso è l unico componente ad avere accesso privilegiato alle risorse del sistema. I processori Intel utilizzano 2 bit per rappresentare i livelli di privilegio(ring). Il livello 0 è quello più privilegiato, mentre il livello 3 è il meno privilegiato. Nelle architetture Intel si adopera il ring deprivileging, cioè il VMM e il guest OS vengono eseguiti a diversi livelli di privilegio. Il VMM opera al livello più privilegiato, Kernel Supervisor Mode, mentre il guest OS e i suoi processi operano nell user mode, il quale si divide in Virtual Kernel Mode e Virtual User Mode. Fig.1.5: Deprivileging. Il sistema operativo guest esegue in User Mode allo stesso modo delle sue applicazioni Il ring deprivileging causa numerosi problemi da affrontare. Innanzitutto abbiamo il ring aliasing, il problema che sussiste nel momento in cui il software viene eseguito ad un livello di privilegio diverso da quello per il quale era stato inizialmente progettato. Un esempio nell IA-32 è dato dall istruzione PUSH, che pone gli operandi nello stack quando viene eseguita con il registro CS (Code Segment). In questo caso il SO si accorge del fatto che non sta eseguendo al livello di privilegio 0. I sistemi operativi si aspettano di avere accesso all intero spazio di indirizzamento virtuale, 6

ma ciò non è più possibile in quanto il VMM riserva per se stesso parte di tale spazio, quindi si ha una compressione dello spazio di indirizzamento. L hypervisor può essere eseguito interamente all interno dello spazio di indirizzamento del guest, il che comporta un facile accesso ai dati del guest, sebbene il VMM potrebbe utilizzare una grande quantità di tale spazio. In alternativa il VMM può eseguire in uno spazio di indirizzamento separato, ma in ogni caso utilizzerebbe una minima parte dello spazio di indirizzamento del guest per il controllo di strutture che permettano le transizioni tra il guest e l hypervisor stesso. Il VMM deve prevedere una protezione alle porzioni dello spazio di indirizzamento che sta utilizzando, per evitare che il guest possa modificare porzioni di codice sensibile. In tal caso si potrebbe compromettere l integrità del VMM e potrebbe avvenire un system fault. Ogni tentativo del guest di accedere a tali porzioni dello spazio di indirizzamento devono quindi innescare una transizione al VMM. Il ring deprivileging può interferire sull efficacia delle transizioni al software Guest ( impatto sulle guest transitions). Nell IA-32 le istruzioni SYSENTER e SYSEXIT sono istruzioni per le chiamate di sistema veloci e per un veloce ritorno da tali system call. L esecuzione della SYSENTER da parte di applicazioni guest provoca una transizione al VMM, che si occupa di simulare l effetto di quella istruzione. L esecuzione della SYSEXIT da parte del guest OS provoca un grave fault al VMM, il quale dovrà quindi simulare ogni esecuzione di tale istruzione. Le architetture Itanium forniscono alle ISR(Interrupt Service Routine ) informazioni riguardo l interrupt e il contesto dell interrupt. Tali dati si trovano all interno del registro di controllo delle interruzioni, e ogni accesso al di fuori del livello di privilegio 0 causa un fault. Chiaramente, se avvengono molti fault, le performance vengono compromesse. Il VMM si occupa di gestire le interruzioni esterne e ha la facoltà di negare al guest l interrupt masking, ossia il meccanismo che permette di disabilitare temporaneamente le interruzioni per eseguire una operazione. Ogni tentativo del guest di controllare l interrupt 7

masking fallisce nel contesto del ring deprivileging, e tali fault possono creare problemi ai sistemi operativi. Per prevenire le modifiche dell interrupt masking senza che il VMM intercetti ogni tentativo del guest, il VMM può mandare al guest delle interruzioni virtuali. Tali interruzioni devono essere consegnate al guest se e solo se esso non sta gestendo interruzioni unmasked, le quali hanno una alta priorità e devono essere servite per prime(es. divisione per 0, o errori di parità nella memoria). Per consegnarle in tempo l hypervisor deve intercettare alcuni tentativi del guest di modificare l interrupt masking, e ciò complica in modo significativo il VMM. Il meccanismo di protezione basato sul ring deprivileging protegge il VMM dal software guest. Il problema è che il guest OS viene eseguito al livello di privilegio 3, lo stesso delle sue applicazioni, e ciò non rispetta il principio dell incapsulamento e della protezione(ring compression). Alcuni componenti dello stato della CPU dell IA-32 non sono rappresentati in registri accessibili dal software. Un esempio è dato dai descrittori nascosti dei registri dei segmenti posti nella cache. Un descrittore di un segmento è una struttura che descrive il segmento di memoria riferito all indirizzo logico. All interno del descrittore vi sono vari attributi, come per esempio il livello di protezione, il tipo di segmento, la grandezza degli operandi. Il registro del segmento copia il suo descrittore nella cache, e questo non viene aggiornato quando il software scrive nella tabella dei descrittori. L IA-32 non prevede meccanismi per salvare o ripristinare questi componenti nascosti quando cambiano le VM o per preservarli durante l esecuzione del VMM(accesso allo stato nascosto).[2] La tecnica tradizionale per effettuare il deprivileging consiste nel meccanismo di trap and emulate: ogni volta che il guest OS tenta di eseguire istruzioni sensibili, l hypervisor le intercetta e simula l effetto che avrebbero dovuto avere tali istruzioni. Ad esempio, quando il SO tenta di disattivare le interruzioni tramite l istruzione CLI(Clear Interrupts ), il VMM viene attivato da una trap (eccezione) e intercetta l istruzione. Per simularla, pone a 0 il 8

registro dell Interrupt Flag(IF), il quale si trova in una struttura dati dedicata alla VMM. Chiaramente l Interrupt Flag del registro fisico della CPU non viene modificato. Nel caso della CPU Intel, se abbiamo un interrupt hardware, esso viene servito dalla ISR del VMM ed in seguito il VMM salta alla corrispondente ISR del guest OS. Il problema del meccanismo di trap and emulate è che non funziona nell architettura Intel x86, in quanto in questa molte istruzioni sensibili non generano alcuna trap. Infatti se un processo utente o il guest OS tentano di eseguire istruzioni sensibili, queste ultime vengono ignorate dalla CPU. Dunque,a causa dei problemi relativi al deprivileging e alla tecnica di trap and emulate, sono state sviluppate delle soluzioni alternative. Ci sono tre fondamentali tecniche di virtualizzazione della CPU: la para-virtualizzazione, la full virtualization senza supporto hardware e la full virtualization con supporto hardware. La para-virtualizzazione consiste nella riscrittura, parziale o totale, del kernel del guest OS e dei driver dei dispositivi per creare un interfaccia più facile da virtualizzare. Tale interfaccia software (hypercall) viene usata dal guest OS al posto delle istruzioni sensibili. L interfaccia deve essere scritta in modo generico e standard affinchè i diversi VMM disponibili sul mercato, come Xen dell Università di Cambridge o Hyper-V della Microsoft, possano interpretarla correttamente. Fig. 1.6: Virtualizzazione vera e Para-virtualizzazione 9

La differenza tra la virtualizzazione vera(trap and emulate) e la para-virtualizzazione, come possiamo notare nella Fig. 1.6, è che nella prima l hardware genera una trap e l hypervisor la emula ed effettua il return. Nella paravirtualizzazione la versione modificata del guest OS, in questo caso Linux, non contiene più istruzioni sensibili. Quando il guest OS necessita di scrivere su un registro interno critico, esso effettua una hypervisor call, del tutto simile a una system call di un processo all interno di una versione non modificata di Linux. La paravirtualizzazione offre performance elevate, di contro però limita i sistemi operativi supportati, infatti il VMM non può eseguire sistemi legacy o proprietari come Windows. Inoltre, nel momento in cui le istruzioni sensibili del guest OS vengono sostituite con chiamate all hypervisor, esso non può più eseguire direttamente sull hardware. Per superare questi limiti viene introdotta la Full Virtualization. La Full Virtualization senza supporto hardware viene introdotta nell hypervisor del VMware per architetture Intel x86 nel 1999. Essa modifica a tempo di esecuzione il codice binario del guest OS, sostituendo istruzioni sensibili con del codice di emulazione(dynamic binary translation). Nell x86 il ring 0 era il ring più privilegiato, e lì eseguiva il kernel. Gli altri 2 ring non venivano usati da nessun sistema operativo, e infine i processi utente si trovavano nel ring 3, il meno privilegiato. Una soluzione per la virtualizzazione è stata porre l hypervisor nel ring 0 e il guest OS nel ring 1. Fig.1.7: Protezione Basata sui ring dell architettura Intel x86. L hypervisor esegue nel ring 0 e il sistema operativo guest nel ring 1 10

L hypervisor riscrive il codice sensibile analizzando un basic block alla volta. Un basic block è un insieme di istruzioni sequenziali che termina con un branch, ossia un salto condizionato al verificarsi di una certa condizione. Se tale blocco contiene istruzioni privilegiate, queste ultime vengono sostituite con una chiamata ad una procedura del VMM che le gestisce. Il branch invece viene sostituito con una chiamata all hypervisor. I blocchi tradotti vengono poi posti in una memoria cache, in tal modo non è più necessario tradurli in futuro. Una volta che il blocco ha completato l esecuzione, il controllo viene ripreso dal Virtual Machine Monitor, il quale alloca il successivo. Se quest ultimo blocco è già stato tradotto, viene eseguito immediatamente, altrimenti viene tradotto,posto nella cache ed eseguito. Questa tecnica ha il vantaggio di permettere l esecuzione di sistemi operativi legacy, ma è molto onerosa in termini di prestazioni, in quanto abbiamo un overhead per la traduzione del codice. 1.2 Tecnologie di Virtualizzazione Intel L obiettivo di eliminare la necessità per le CPU di usare tecniche di paravirtualizzazione e di traduzione binaria dinamica e di implementare VMM che possano supportare un ampia gamma di guest OS non modificati mantenendo alte performance, ha indotto a sviluppare la Full Virtualization con supporto hardware, che è la tecnologia di virtualizzazione maggiormente impiegata al giorno d oggi. In particolare, la Tecnologia di Virtualizzazione Intel include un supporto per la virtualizzazione per le architetture Itanium (VT-i) e IA-32 (VT-x). 11

1.2.1 Architettura VT-x Nell architettura VT-x abbiamo due possibili operazioni: le operazioni VMX root e VMX non root. VMX non-root mode Ring 3 Guest apps Ring 2 Ring 1 VMExit Ring 0 Guest OS VMCS Control data Intel VT What events to trap Why did a trap occur VMEntry Ring 3 Ring 2 Ring 1 Ring 0 Host apps VMM or Host OS Guest state Host state Load at VMEntry Load at VMExit VMX root mode Fig.1.8 : VMX root mode e VMX non root mode Le operazioni nel VMX root mode sono le operazioni del VMM, e sono molto simili a quelle dell IA-32 senza la tecnologia VT-x. Le operazioni nel VMX non root mode invece forniscono un alternativa all ambiente IA-32 controllato dal VMM e progettato per supportare una Macchina Virtuale. Come si può notare dalla Fig.1.8, entrambe le operazioni supportano i 4 livelli di privilegio. La novità introdotta dalla VT-x sono due tipi di transizione : la transizione da VMX root mode a VMX non root mode, chiamata VM entry, e la transizione da VMX non root mode a VMX root mode chiamata VM exit. Le VM entry e le VM exit sono gestite da una nuova struttura, il VMCS(Virtual Machine Control Structure). Il VMCS include un area di stato guest e un area di stato host, ognuna delle quali contiene dei campi corrispondenti a diversi componenti dello stato della CPU. Ogni CPU virtuale ha una apposita VMCS, ma soltanto una VMCS alla volta è attiva sulla CPU fisica. Le VM entry caricano lo stato del processore dall area di stato guest, mentre le VM exit salvano lo stato del processore nell area di stato guest e poi caricano lo stato della CPU dall area di stato host. Il cambiamento più importante riguarda le operazioni nel VMX non 12

root mode. Infatti in questa modalità ci sono eventi e istruzioni che provocano una VM exit, alcune delle quali in modo incondizionato, così da non poter mai eseguire nella modalità VMX non root. Altre istruzioni e tutti gli eventi possono essere configurati per operare in questo modo usando i campi di controllo dell esecuzione del VM(VM exeution control fields ) presenti nel VMCS. L area di stato guest del VMCS contiene gli elementi dello stato della CPU virtuale associata al VMCS. Alcuni registri devono essere caricati da ogni VM exit affinché le operazioni del VMM siano corrette. Per esempio, ci sono registri che gestiscono le operazioni del processore, come i segment register, che mappano gli indirizzi logici in lineari, il CR3, che mappa gli indirizzi lineari in fisici, l IDTR per la consegna degli eventi e tanti altri. Inoltre l area di stato guest contiene dei campi corrispondenti ad elementi dello stato del processore che non sono mantenuti in nessun registro accessibile da software. Un di questi elementi è lo stato di interrompibilità del processore, il quale indica se le interruzioni esterne sono temporaneamente mascherate,oppure se interruzioni non mascherabili (NMI ) sono in coda in quanto il software sta gestendo una precedente NMI. Il VMCS contiene dei campi che controllano le operazioni VMX non-root, ed essi specificano le istruzioni e gli eventi che hanno provocato la VM exit. Il VMCS include dei controlli che supportano la virtualizzazione degli interrupt. Il primo controllo è l External Interrupt Exiting, e quando viene settato causa la VM exit dopo ogni interruzione esterna. Il secondo è l Interrupt Window Exiting, che,quando è abilitato, determina una VM exit ogni volta che il guest è pronto a ricevere interruzioni. Infine abbiamo l Use TPR shadow, che gestisce gli accessi al TPR(task priority register) dell APIC( Advanced Programmable Interrupt Controller) tramite il registro di controllo CR8: ogni esecuzione dell istruzione MOV CR8 accede a una copia del TPR(TPR shadow) referenziata da un puntatore nel VMCS. Ci sono anche dei campi di controllo dell esecuzione della VM che supportano una efficiente virtualizzazione dei registri di controllo CR0-CR4. Questi registri includono dei 13

bit che controllano le operazioni della CPU. L hyprvisor può mantenere il controllo di alcuni di questi bit. Il VMCS possiede, per ciascuno di questi registri, una maschera host/guest che il VMM usa per indicare quale bit deve proteggere. Ogni tentativo del guest di scrittura su un bit protetto innesca una VM exit. Per supportare la flessibilità del VMM, il VMCS include delle bitmap che consentono al VMM di selezionare le cause di alcune VM exit. Le principali sono :la bitmap delle eccezioni, le bitmap I/O e le bitmap MSR. L exception bitmap è un campo di 32 bit e ad ogni bit associa una eccezione. Quando si solleva un eccezione, il suo vettore seleziona un bit in questo campo. Se il bit è 1 avviene una VM exit. Le bitmap I/O contengono una entry per ogni porta nello spazio a 16 bit. Se queste bitmap vengono utilizzate, l esecuzione di una istruzione di I/O determina una VM exit. Le bitmap MSR(Model Specific Register) contengono due entry, una per la lettura e una per la scrittura, per ciascun MSR attualmente usato. Se vengono utilizzate tali bitmap, l'esecuzione di RDMSR o WRMSR causa una VM exit se essa tenta di leggere o scrivere sul registro MSR il cui bit di lettura/scrittura è settato nella bitmap MSR. Ogni VMCS è referenziato tramite un indirizzo fisico, e ciò elimina la necessità di allocare il VMCS nello spazio di indirizzamento lineare del guest. La struttura e il formato del VMCS non è architetturalmente definito, e ciò consente delle ottimizzazioni per migliorare le performance delle operazioni VMX non root e per ridurre il tempo di latenza delle VM entry e delle VM exit. Le VM entry, nel contesto della VT-x, oltre a caricare lo stato del processore nell area di stato guest del VMCS, possono anche essere configurate per un iniezione di eventi. La CPU effettua tale iniezione usando l IDT (Interrupt Descriptor Table, tabella usata per determinare la risposta corretta alle interruzioni) del guest. Il processore consegna quindi un interruzione o un eccezione specificata dal VMM come se questa fosse avvenuta dopo la VM entry. Questa caratteristica fa in modo che il VMM non debba più simulare la consegna 14

di questi eventi. Per quanto riguarda le VM exit, esse salvano lo stato del processore nell area di stato guest e caricano lo stato della CPU dall area di stato host. Per questo ogni VM exit ha un punto di entrata in comune. Tutte le VM exit salvano nel VMCS informazioni dettagliate sul motivo dell uscita, specificando per esempio l istruzione o l evento che l ha causata.[2] 1.2.2 Architettura VT-i VT-i espande l architettura Itanium con estensioni all hardware del processore e al PAL(Processor Abstraction Layer) del firmware. La novità della VT-i è l introduzione del bit PSR.vm(Processor Status Register). Quest ultimo permette al guest OS di eseguire al livello di privilegio per il quale era stato progettato e di effettuare intercettazioni al VMM necessarie per la creazione di una macchina virtuale completa. Il VMM esegue quando tale bit è 0, mentre il software guest esegue quando il bit è 1. Il PSR.vm modifica il comportamento di tutte le istruzioni privilegiate e alcune di quelle non privilegiate che accedono ad uno stato controllato dal VMM.Quando il guest OS esegue una di tali istruzione avviene un intercettazione che trasferisce il controllo all hypervisor resettando il bit PSR.vm. Questo registro permette anche di controllare il numero di bit degli indirizzi virtuali disponibili. Quando il VMM è in esecuzione (PSR.vm=0) tutti i bit di indirizzi virtuali sono disponibili. Quando il guest è in esecuzione, il bit di indirizzo virtuale più alto non è più disponibile, e avvengono dei fault o delle trap se questo bit viene usato. Ciò fornisce al VMM uno spazio di indirizzamento dedicato a cui il guest non può accedere. 15

Fig.1.9 : Schema di funzionamento dell architettura VT-i VT-i include anche delle integrazioni al livello PAL del firmware. Queste integrazioni forniscono un interfaccia di programmazione consistente al VMM, anche se l hardware viene implementato diveramente nei processori di diverse generazioni. Tali estensioni del PAL includono un set di nuove procedure : l aggiunta di servizi del PAL per operazioni del VMM ad alta frequenza e la tabella dei descrittori dei processori virtuali(vpd). Le procedure del PAL servono a creare o ad abbattere un ambiente di esecuzione della macchina virtuale, ad inizializzare o a terminare processori virtuali, a salvare o a ripristinare gli stati del processore virtuale. I servizi del PAL sono un interfaccia per la virtualizzazione. Essi forniscono funzionalità per sincronizzare registri del guest, per riprendere l esecuzione del software guest dopo un interruzione virtuale, per configurare interrupt pendenti. La tabella VPD è allocata in memoria, nello spazio di indirizzamento del VMM. Essa contiene impostazioni per la configurazione del processore virtuale e alcuni stati del processore virtuale che influenzano le caratteristiche della sua esecuzione, come ad esempio alcuni valori di registri di controllo del processore. 16

All interno del VPD ci sono due campi che consentono all hypervisor di personalizzare l ambiente di virtualizzazione.il primo è il campo di accelerazione della virtualizzazione, che consente di personalizzare la virtualizzazione di particolari risorse o istruzioni, riducendo le intercettazioni che il VMM deve manipolare. Il secondo è il campo di disabilitazione della virtualizzazione, che permette al VMM di disabilitare la virtualizzazione di specifiche istruzioni/risorse. Per la gestione efficiente delle intercettazioni della virtualizzazione, l architettura ha aggiunto due vettori nell IVT(Interruption Vector Table):il vettore di virtualizzazione, il quale è usato per le intercettazioni relative alla virtualizzazione, e il vettore delle interruzioni virtuali esterne, usato quando il guest smaschera un interrupt esterno pendente.[2] 1.2.3 Classificazione delle primitive Intel Le architetture IA-32 e Itanium includono specifiche istruzioni, registri e tabelle. Nell IA-32 i registri di controllo determinano le modalità di funzionamento del processore. In particolare CR0 contiene dei flag che controllano lo stato del processore, CR1 è riservato, CR2 contiene gli indirizzi lineari che hanno provocato un page fault, CR3 contiene l indirizzo base della tabella delle pagine, CR4 comprende un gruppo di flag che abilitano alcune estensioni architetturali, infine CR8 specifica il valore di soglia che il SO usa per controllare la classe di priorità delle interruzioni esterne. [4] Un registro molto importante dell architettura IA-32 è il registro EFlag. Esso viene usato per controllare l interrupt masking, ossia il meccanismo che evita la consegna dell interrupt se il sistema operativo non è pronto a riceverle. Il bit usato per mascherare le interruzioni è l IF(Interrupt Flag), nell Itanium invece viene usato il bit i all interno del registro PSR(Processor Status Register). La consegna delle eccezioni e delle interruzioni viene 17

controllata dalla tabella dei descrittori dell interrupt, o IDT, mentre nell architettura Itanium la tabella che svolge questa funzione è la IVT(Interrupt Vector Table). L istruzione per trasferire i dati è MOV nell IA-32, mov nell Itaniumm, ed entrambe includono versioni che consentono di leggere e scrivere all interno dei registri di controllo. Entrambe le architetture hanno delle istruzioni che accedono allo stato privilegiato e che non falliscono se eseguite senza privilegio.per esempio nell IA-32 i registri GDTR,LDTR, IDTR e TR contengono dei puntatori a strutture dati che controllano la CPU. Software non privilegiato può leggere da questi registri tramite le istruzioni SGDT,SIDT,SLDT,STR, mentre per scrivere in tali registri bisogna usare le istruzioni LGDT, LIDT,LLDT,LTR al livello di privilegio 0. Un altro esempio riguarda il registro PTA(Page Table Address) di Itanium, al cui interno vi è l indirizzo base del VHPT(Virtual Hash Page Table). Per accedere al registro bisogna usare l istruzione mov PTA al ring 0. L istruzione thash(translation hashed entry address instruction), espone in parte o per intero l indirizzo base del VHPT, e può essere eseguita al di fuori del livello più privilegiato.[2] 1.3 Virtualizzazione sull Architettura ARM L architettura ARM è una famiglia di microprocessori RISC a 32 bit sviluppata dalla società ARM Holdings ed è utilizzata principalmente nei sistemi embedded e nei dispositivi mobili per il suo basso consumo energetico.[19] Le architetture ARM non erano virtualizzabili secondo i requisiti definiti da Popek e Goldberg[3],infatti c erano molte istruzioni sensibili non privilegiate che avevano un comportamento imprevedibile quando il guest OS eseguiva in modalità non privilegiata. Inoltre nei server tradizionali, basati su processori PowerPC o x86, era adottato l hypervisor KVM (Kernel-based Virtual Machine), ma non esistevano implementazioni del KVM 18

disponibili per l architettura ARM. Per tale motivo è stato sviluppato un hypervisor basato su KVM compatibile con le architetture ARM, cioè ARMvisor. In ARMvisor viene adottato il metodo della paravirtualizzazione, che sostituisce le istruzioni sensibili non privilegiate con un insieme di hypercall predefinite. Nonostante le prestazioni presentino risultati importanti a tempo di esecuzione, il costo ingegneristico per portare un guest OS su una macchina virtuale è molto elevato, e aggiunge difficoltà alla manutenzione di nuove versioni del sistema operativo guest. Per risolvere tali limitazioni è stata proposta una tecnica chiamata pre-virtualizzazione. Essa presenta un meccanismo semi-automatico di riscrittura delle istruzioni sensibili in assembler. Questo approccio non solo richiede minori modifiche del guest OS, ma ottiene anche gli stessi risultati della paravirtualizzazione. ARM v6 definisce 31 istruzioni sensibili, 7 delle quali sono privilegiate. Le rimanenti sono istruzioni critiche che richiedono una correzione del codice per prevenire un comportamento non deterministico. Forzare le istruzioni sensibili non privilegiate(istruzioni critiche) a generare una trap per l emulazione dell istruzione avrebbe portato ad un intollerabile degradazione delle performance. Di conseguenza, le trap sono eliminate e sostituite con lo Shadow Register File Access(SRFA) nello spazio di indirizzamento guest. L SRF è un registro che mappa gli stati della CPU virtuale del Register File su una regione di memoria accessibile sia dal VMM che dal guest coi permessi di lettura e scrittura. Al contrario delle istruzioni critiche, alcune istruzioni sensibili sono anche privilegiate. Quando esse vengono eseguite nello spazio utente di ARM, generano delle trap e ARMvisor deve emulare l effetto della loro esecuzione(trap and emulate). Per ridurre l overhead dovuto all emulazione sono stati proposti alcuni miglioramenti. Innanzitutto, le operazioni di cancellazione del TLB (Translation Lookaside Buffer) e del BTB( Branch Target Buffer) sono sostituite con l istruzione NOP(No Operation), in quanto la cancellazione viene effettuata durante i context switch tra guest e hypervisor. In secondo luogo, le operazioni di 19

lettura nei coprocessori sono sostituite con l SRFA, dato che viene prelevato solo lo stato virtuale. Infine, le operazioni della cache che coinvolgono l hardware generano una trap e vengono completate all interno del livello di privilegio. Per ridurre i costi del cambio di contesto viene utilizzata una tecnica chiamata FIT(Fast Instruction Trap), che consiste in una serie di macro che codificano le informazioni delle istruzioni sostituite. In questo modo l overhead dell emulazione è più basso in quanto le istruzioni possono essere gestite senza un cambio di contesto ad ARMvisor. Nell architettura ARM manca un supporto hardware per le eccezioni, l hypervisor è quindi responsabile della consegna delle trap a ciascuna macchina virtuale. Le interruzioni sincrone come le system call hanno una priorità alta e devono essere subito iniettate nella macchina virtuale. Le interruzioni asincrone invece possono essere consegnate dopo, quando la coda delle interruzioni sincrone della VM è vuota.[18] 1.4 Virtualizzazione della Memoria I sistemi operativi supportano il meccanismo della memoria virtuale, che consiste nel mappare lo spazio di indirizzamento virtuale sulla memoria fisica. Il mapping è contenuto nella tabella delle pagine. Il caricamento di una pagina del processo in memoria avviene a domanda, ossia solo quando il processo ha bisogno di quella pagina. Se la pagina non è presente in memoria centrale viene sollevata un eccezione( page fault), e il SO dovrà recuperarla in memoria secondaria. Il meccanismo della virtualizzazione complica molto la gestione della memoria. In generale, per ogni macchina virtuale il VMM crea una tabella delle pagine ombra (shadow page table) che mappa le pagine virtuali sulle pagine della memoria fisica. Ogni volta che il sistema operativo guest cambia la sua tabella delle pagine, l hypervisor deve aggiornare la sua shadow page table(spt). La difficoltà sta nel fatto che il guest OS 20

cambia le sue page table scrivendo in memoria. Per questa operazione non è richiesta nessuna istruzione sensibile, quindi il VMM non viene a conoscenza di tale modifica e non può aggiornare la SPT. Fig. 1.10: Remapping degli indirizzi in memoria tramite la shadow page table Una possibile soluzione per l hypervisor è di tenere traccia di quali pagine nella memoria virtuale del guest contengono la page table del livello superiore. Esso può ottenere questa informazione la prima volta che il guest cerca di caricare il registro hardware che punta a tale tabella, in quanto questa istruzione è sensibile e genera una trap. A questo punto il VMM crea la shadow page table e mappa la tabella delle pagine del livello superiore. In seguito, ogni tentativo del guest di modificare la tabella delle pagine determina un page fault. L hypervisor analizza dunque il flusso di istruzioni e aggiorna la sua SPT. Un altra soluzione consiste nel fare l opposto: quando il guest modifica la propria tabella delle pagine, il VMM non aggiorna la shadow page table. Nel momento in cui il guest cerca di accedere ad una nuova pagina,avviene un fault e l hypervisor riprende il controllo. Quest ultimo ispeziona la tabella delle pagine del guest per verificare se ci sono nuovi mapping da aggiungere, aggiorna la SPT e riesegue l istruzione che ha provocato il fault. Nel caso in cui il guest rimuova un mapping dalla sua tabella delle pagine tramite l istruzione INVLPG, l hypervisor intercetta questa istruzione e rimuove il mapping dalla sua SPT. 21

Entrambe le tecniche sono molto onerose in termini di prestazioni, in quanto avvengono molti page fault: abbiamo infatti sia i page fault indotti dall hypervisor per allineare la SPT con la tabella delle pagine guest, sia i page fault indotti dal guest quando non trova una pagina. In quest ultimo caso tali fault vengono intercettati dal VMM e reiniettati nella macchina virtuale. I page fault in un ambiente virtuale determinano le VM exit, nelle quali il VMM ottiene di nuovo il controllo. Per effettuare una VM exit, la CPU registra quale evento l ha causata, in più registra l indirizzo dell istruzione che il guest stava eseguendo. In seguito il processore effettua il cambio di contesto, salvando tutti i registri utilizzati in quel momento, e carica lo stato dell hypervisor. Solo dopo queste operazioni il VMM può gestire il page fault, e durante questo processo vengono impiegati migliaia di cicli del clock. [1] Per risolvere tale sfida è necessario un supporto hardware. L Intel introduce un livello aggiuntivo di traduzione degli indirizzi mediante le Extended Page Tables(EPT). Adesso,oltre agli indirizzi virtuali del guest, abbiamo gli indirizzi fisici del guest e gli indirizzi fisici dell host(chiamati anche indirizzi fisici della macchina). La tabella delle pagine traduce gli indirizzi lineari in indirizzi fisici, mentre la tabella EPT traduce gli indirizzi fisici guest in indirizzi fisici host usati dalla memoria. Il risultato è che il software guest può modificare la sua tabella delle pagine e gestire in maniera diretta i page fault. Ciò permette al VMM di evitare le VM exit associate alla virtualizzazione della tabella delle pagine.[2] La presenza di tante macchine virtuali sulla stessa piattaforma hardware può comportare un eccessivo impiego della memoria, in quanto la quantità di memoria richiesta dall hypervisor per tutte le VM potrebbe essere maggiore dell effettiva quantità di memoria fisica presente sul sistema. Per ovviare a tale situazione, una soluzione è fornita dalla tecnica della deduplicazione, che permette alle macchine virtuali di condividere delle pagine comuni, evitando di conservare gli stessi dati due volte. Nel caso in cui, nonostante l utilizzo di tale tecnica,persista una assenza di spazio libero in memoria, l hypervisor può spostare alcune 22

pagine in memoria secondaria. Il punto è che il VMM non sa quali siano le pagine meno usate, ed è molto probabile che scelga di trasferire le pagine sbagliate. Una soluzione comune a tale scopo è la prelazione delle pagine (ballooning). Essa consente al VMM di collaborare con l algoritmo di sostituzione del guest OS per liberare spazio in memoria. Il balloning consiste nel caricare in ogni VM un piccolo modulo del kernel (balloon). Tale modulo alloca pagine virtuali nella VM e ciò aumenta l esiguità della memoria del guest. A questo punto, il guest comincia a rimuovere le pagine che ritiene meno importanti tramite il proprio algoritmo di sostituzione. Una volta che il guest ha completato il page out, il balloon si sgonfia e comincia a deallocare le precedenti pagine virtuali. 1.5 Virtualizzazione dell I/O Le attività di I/O(Input Output) sono relative al trasferimento di dati in ingresso al calcolatore e alla restituzione dei risultati dell elaborazione. Un esempio è costituito dal trasferimento di un dato da un supporto esterno alla memoria del computer. Affinché la periferica possa funzionare correttamente c è bisogno di un modulo software, detto driver, che si occupa di fornire una interfaccia software che semplifica le operazioni del sistema operativo. Nell ambito della virtualizzazione, il guest OS interroga il bus per trovare i dispositivi connessi. Ciò provoca una trap che il VMM intercetta, e in seguito quest ultimo fornisce al guest una simulazione del dispositivo hardware(i/o full virtualization). In generale i dispositivi virtuali forniti dall hypervisor sono più semplici di quelli realmente presenti sulla macchina,ciò implica che vi sia un disaccoppiamento tra il software front-end e l implementazione back-end usata dal codice di emulazione per la semantica delle operazioni. In questo modo, è possibile cambiare l hardware senza dover aggiornare il software. Quando il guest OS tenta di leggere/scrivere i registri del device virtuale, il VMM 23

intercetta tali istruzioni e copia i valori da/verso i registri hardware. Se il dispositivo fisico genera un interruzione, l hypervisor la serve simulando un interrupt nel contesto della VM. Fig.1.11: I vari livelli dell I/O Full Virtualization. Il VMM è responsabile delle operazioni di I/O sui dispositivi, della gestione delle trap e della simulazione del device fisico L approccio dell I/O full dovuto all emulazione e virtualization risulta poco efficiente in quanto c è un overhead al passaggio attraverso il VMM, e per questo viene sviluppata la paravirtualizzazione I/O. In questa tecnica il VMM esporta al guest OS delle aree di memoria condivisa(memory mapped I/O) e delle istruzioni speciali per l I/O(port mapped I/O). Il guest OS quindii carica un driver apposito per l I/O paravirtualizzato, e tramite quest ultimo accede in modo esclusivo alla periferica, senza passare attraverso il VMM( device pass through). Il guest OS effettua operazioni di indirizzi fisici al dispositivo, tuttavia il device non deve usare gli I/O indicando i suoi indirizzi forniti dalla macchina virtuale, ma quelli forniti dall hypervisor. A tal fine, esiste l I/O Memory Management Unit (I/O MMU), il quale usa una tabella delle pagine per tradurre gli indirizzi di memoria a cui il dispositivo vuole accedere in indirizzi fisici indicati dal VMM. L I/O MMU supporta anche l interrupt remapping, al fine di inoltrare gli interrupt dei dispositivi alla giusta VM. 24

La soluzione descritta in precedenza risulta essere poco scalabile, in quanto all aumentare delle VM risulta difficile assegnare in modo esclusivo un dispositivo ad ogni macchina virtuale. L idea per superare questa difficoltà è di condividere i dispositivi tra più VMM, ed è alla base della Single Root I/O Virtualization o SRIOV, una specifica supportata dall hardware PCIe( Peripheral Component Interconnect Express). Nella SR-IOV il controller del dispositivo fornisce un interfaccia, uno spazio di memoria, interrupt e un canale per il DMA. I due tipi di funzioni presenti nella SRIOV sono le funzioni fisiche(pf), usate per configurare e controllare i device con lo standard seriale PCIe, e le funzioni virtuali(vf), cioè funzioni associate alle PF che condividono una o più risorse fisiche con queste ultime[11]. Il guest non può accedere alle PF, mentre le VF sono progettate per le macchine virtuali. La SR-IOV,quindi, permette la virtualizzazione dei dispositivi in migliaia di funzioni virtuali usate dalle VM. Per realizzare una virtualizzazione dell I/O scalabile e con elevate prestazioni è stato sviluppato un secondo approccio chiamato self-virtualized devices (dispositivi autovirtualizzati ). Un dispositivo I/O self-virtualized è una periferica con delle risorse computazionali aggiuntive vicine al dispositivo fisico. Tali risorse contengono alcune funzionalità per la virtualizzazione dell I/O. In particolare, il dispositivo deve effettuare il multiplexing e il demultiplexing di un grande numero di dispositivi virtuali mappati su un singolo dispositivo fisico, deve fornire una interfaccia all hypervisor per la gestione efficiente dei device, e deve controllare la potenza di calcolo offerta dalla sottostante piattaforma hardware. Ogni dispositivo viene rappresentato da una VIF(Virtual Interface Function), la quale esporta un interfaccia ben definita al guest OS. Le due funzioni principali dei device self-virtualized sono di gestire le VIF ed eseguire l I/O. La gestione delle VIF include la creazione/ distruzione delle VIF o la configurazione di alcuni parametri associati ad esse. Per quanto riguarda l I/O, un messaggio mandato dal guest viene ricevuto dal dispositivo tramite una coda (send queue) del VIF, e analogamente il dispositivo manda 25

dati nell altra direzione tramite una periferica di comunicazione, e sempre con la mediazione del VIF, questi dati vengono posti in una coda (receive queue), pronti per essere letti dal guest.[10] 26

Capitolo 2: Le Architetture VMware e Xen 2.1 L hypervisor VMware Workstation A partire dal 1999, l azienda VMware inizia a fornire soluzioni per la virtualizzazione di desktop,server, cloud, e anche di cellulari. Oltre ai Virtual Machine Monitor, produce software in grado di gestire le macchine virtuali su larga scala. VMware Workstation è un hypervisor di tipo 2, ed è stato il primo prodotto dell azienda. L idea di usare macchine virtuali inizia a diffondersi negli anni 60 e 70 del Novecento, sia nell industria dei computer, sia nelle ricerche universitarie. Con l avvento dei personal computer negli anni 80, però, l interesse per la virtualizzazione svanisce. Bisogna aspettare fino al 1997 quando tre dei futuri fondatori di VMware realizzano un primo prototipo di hypervisor chiamato Disco, con l obiettivo di eseguire sistemi operativi su una larga scala di multiprocessori sviluppati a Stanford, cioè i multiprocessori FLASH. Durante la realizzazione del progetto, viene osservato che l uso delle macchine virtuali avrebbe potuto risolvere molti problemi software senza dover sviluppare nuovi sistemi operativi, ma semplicemente aggiungendo un livello tra l hardware e il SO. VMware viene fondata nel 1998 con l obiettivo di portare la virtualizzazione nell architettura x86 e nell industria dei computer. Il prodotto VMware Workstation presenta due varianti: VMware Workstation for Linux e VMware Workstation for Windows.[1] L architettura x86 presentava alcuni problemi da affrontare: in primo luogo non era virtualizzabile, in quanto conteneva istruzioni sensibili non privilegiate, che violavano i criteri definiti da Popek e Goldberg [3]. In secondo luogo era molto complessa, basti pensare che c erano quattro modalità di operazioni, ciascuna delle quali abilitava in modi diversi la segmentazione,il paging, i livelli di protezione e la sicurezza. Una terza sfida da affrontare era il grande numero di periferiche, ognuna delle quali aveva un driver specifico, e 27

virtualizzare tali periferiche era molto complicato. Infine, gli hypervisor classici erano installati in azienda. L obiettivo di VMware era fare in modo che i suoi utenti potessero aggiungere gli hypervisor a sistemi già in funzione. L approccio adottato da VMware Workstation è l utilizzo della traduzione binaria dinamica (Full Virtualization senza supporto hardware). Nonostante questa tecnica sia abbastanza efficiente, essa comporta un rallentamento del sistema. La soluzione a questo problema include due fattori chiave. Innanzitutto, sebbene l esecuzione diretta tramite trap and emulate non possa essere impiegata su tutta l architettura x86, essa può essere usata in alcune circostanze. Infatti, ci sono alcune istruzioni che risultano essere sensibili solo in alcune situazioni. Un esempio è l istruzione POPF(Pop flags),che è sensibile solo quando eseguita nel contesto del sistema operativo e non quando eseguita a livello utente. Per questo motivo, all interno di VMware Workstation ci sono due sottosistemi: il sottosistema di esecuzione diretta e quello di traduzione binaria. C è inoltre un algoritmo di decisione che determina quale sottosistema utilizzare (Fig. 2.1). Fig. 2.1: Blocchi modulari del VMM di VMware. Entrambi i sottosistemi si affidano a moduli condivisi L algoritmo presenta dei parametri di input in base ai quali effettua la decisione. Nel caso della traduzione binaria essa viene scelta se una delle seguenti condizioni risulta vera: 1. La macchina virtuale sta eseguendo nel Kernel Mode(ring 0). 2. La VM può disabilitare le interruzioni ed eseguire istruzioni di I/O. 28

3. La VM sta eseguendo nella real mode, una modalità di esecuzione legacy usata dal BIOS. Il secondo fattore chiave è l opportuna configurazione dell hardware usando il meccanismo di protezione dei segmenti, in modo che la traduzione dinamica binaria possa eseguire velocemente senza rallentamenti. Un esempio è una semplice istruzione che effettua un accesso in memoria. Il VMM di VMware configura l hardware, e in questo modo l hypervisor usa la shadow page table e il Memory Management Unit(MMU). Inoltre VMware usa un approccio simile allo shadowing per la tabella di descrittori dei segmenti. Al fine di assicurare che il software all interno della VM non interferisca con il VMM (software fault isolation), VMware divide lo spazio di indirizzamento in due zone separate. Una parte dello spazio viene riservata al VMM, circa 4 MB, mentre il rimanente spazio viene utilizzato dalla macchina virtuale. La decisione di impiegare VMware al di sopra di un sistema operativo host lo rende un hypervisor di tipo 2. Questa scelta comporta due vantaggi: il primo è che VMware implementa l emulazione front-end dei dispositivi, e lascia l implementazione back-end ai driver del software host, il secondo sta nel fatto che il prodotto può essere installato come una normale applicazione utente. L architettura di VMware presenta tre componenti, che hanno diverse funzioni e operano in modo indipendente: I. Il VMX, un programma nello spazio utente che effettua l emulazione del dispositivo fisico,avvia la macchina virtuale ed effettua le chiamate di sistema al SO host. II. Il VMX-driver, un piccolo driver nel kernel mode, usato per permettere al VMM di eseguire sospendendo temporaneamente il sistema operativo host. III. Il VMM, che viene eseguito nel kernel mode fuori dal contesto del sistema operativo host. C è una sola istanza del VMM per ogni macchina virtuale. 29