Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web

Transcript

1 ALMA MATER STUDIORUM UNIVERSITÀ DI BOLOGNA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Parole chiave: Macchine virtuali, World Wide Web, Sistemi Operativi, Portabilità, Network Computing Tesi di laurea di: Mattia Gentilini Relatore: Renzo Davoli I Sessione Anno Accademico 2005/2006

2 2006 Mattia Gentilini. Alcuni diritti riservati. Questo testo è distribuibile liberamente secondo la licenza Creative Commons Attribuzione Condividi allo stesso modo 2.5 Italia. La versione più aggiornata di questo testo è disponibile per il download dal sito Mattia Gentilini. Some rights reserved. This text is freely distributable under the terms of the Creative Commons Attribution Share Alike 2.5 Italy license. An updated version of this text is available for download at

3 Perception: Our day in, day out world is real. Reality: That world is a hoax, an elaborate deception spun by all powerful machines of artificial intelligence that control us. Whoa. TAGLINE PER I POSTER DI THE MATRIX

4

5 Sommario 1 Introduzione Zoo di sistemi operativi: Idea e scenario Motivazioni e vantaggi dello zoo Storia e classificazioni dei sistemi di emulazione Breve storia Classificazione delle macchine virtuali La classificazione secondo Virtual Square La classificazione secondo Smith e Nair Esempi di emulazione Macchine virtuali complete QEMU VMware Microsoft Virtual PC e Virtual Server PearPC Mac on Linux Macchine paravirtuali complete Xen Denali Virtualizzazione del sistema operativo User Mode Linux Virtuozzo e OpenVZ Linux VServer Virtualizzazione a livello di processo Virtualizzazione di rete: VDE (Virtual Distributed Ethernet) Virtualizzazione di rete: Ale4NET Virtualizzazione di file system Virtualizzazione di CPU: Apple Rosetta e Universal Binary Virtualizzazione generale: View OS/UMView Virtualizzazione di linguaggio di programmazione Java CORBA (Common Object Request Broker Architecture) Microsoft.NET Network Computing VNC (Virtual Network Computing) Windows Terminal Services NX Technology Esempi di sistemi di test per OS accessibili da Internet HP Test Drive Linuxzoo Workspot Free Live OS Zoo: A Virtual Machine Support with Web access User Manual Introduction Requirements Usage without networking

6 3.1.4 Usage with networking Known issues Provider Manual Introduction Requirements Installation The public files The management scripts Networking Customization Configuration constants Managing images FLOZ Internals The images FLOZ back end: QEMU VNC server FLOZ front end: PHP and Java applet PHP and XML ZooImageList class VNCInstanceList class common.php: verifypid() functions common.php: web standards and browser compatibility The Java applet Description of FLOZ algorithm Performance Emulation speed VNC speed FLOZ networking support Security Future developments for FLOZ VNC traffic encryption and connection control Client side networking inside Java applet A dedicated secure channel: vde_cryptcab The improved networking algorithm Considerations Image to image networking User customizable images Multi user access to images Load management policies Conclusioni Bibliografia Ringraziamenti

7 1 INTRODUZIONE Mia madre non aveva poi sbagliato a dir che un laureato conta più di un cantante. FRANCESCO GUCCINI, L AVVELENATA Il Sistema Operativo (OS1) è certamente una delle componenti più importanti dei computer moderni, un importanza che è andata aumentando nel tempo. Fino alla metà degli anni 70 il computer era sempre stato concepito come entità unica ed indivisibile comprendente hardware e software, e molto spesso anche i servizi e l assistenza del produttore. I computer di allora erano costosi e difficili, sia da programmare che da utilizzare, e quindi era quasi una necessità che l organizzazione interna del computer, la gestione del rapporto tra hardware e software e la loro manutenzione fossero demandati alla casa produttrice del computer stesso. Poi il computer si è avvicinato alle masse, prima lentamente poi più velocemente. La Xerox, con i suoi Alto e Star, e soprattutto la Apple, con Apple II, contribuirono a questo avvicinamento producendo sistemi molto più accessibili alle tasche degli acquirenti e di ingombro accettabile, oltre che facili da usare e funzionali, per gli standard dell epoca (l interfaccia grafica di Alto e Star, diretta progenitrice di MacOS e quindi di tutte le GUI moderne, è ancora oggi per certi versi superiore ad esse). Altri seguirono l esempio, e alla fine degli anni 70 c era un fiorito universo di microcomputer a costi relativamente bassi e sufficientemente facili da usare. Anche per mantenere i costi bassi, il computer stava separandosi dai servizi offerti dal produttore, ma hardware e software rimanevano intimamente legati tra loro. 1 Da qui in avanti si userà OS (Operating System) per indicare sistema operativo sia al singolare che al plurale (in italiano). 7

8 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web Iniziarono così vari tentativi di dare interfacce applicative comuni a una tale pletora di sistemi diversi tra loro. Il più riuscito [Cha2003] fu CP/M2 (Control Program/Monitor o Control Program for Microcomputers), della (Intergalactic) Digital Research di Gary Kildall. Esso girava su molte delle architetture disponibili all epoca, ma la mancanza di standard hardware condivisi rendeva l interoperabilità comunque scarsa: un programma sviluppato per CP/M doveva essere distribuito in varie versioni, compilate diversamente ed anche su supporti diversi, a seconda del microcomputer sul quale dovevano funzionare. Il fattore decisivo per far salire in primo piano i sistemi operativi come CP/M fu il lancio del PC IBM nel La lungimiranza di Bill Lowe e degli altri componenti del progetto Acorn (il nome usato nella fase di preparazione) nel dare al nuovo sistema un interfaccia aperta ed espandibile, con la possibilità di inserire schede periferiche e una specifica pubblica del BIOS, permisero da un lato la creazione di uno standard hardware imperante ormai da anni, dall altro una nuova concezione del computer stesso. Se prima il computer era una scatola chiusa, ora infatti diventava una collezione di componenti standardizzati forniti da un ampia varietà di produttori. Siccome l acquisto di un computer (come di qualsiasi altra apparecchiatura) è sempre stato deciso in base a ciò per cui poteva servire, ora a determinare questa caratteristica era il software, ed in particolare il sistema operativo, punto di collegamento tra il software e l hardware. Se oggi una persona vuole usare una certa applicazione, prima sceglie un sistema operativo per il quale tale applicazione sia disponibile, poi l hardware sul quale tale dispositivo funzioni. Dunque il sistema operativo, ormai da molti anni, è l elemento centrale di un computer. Proprio su di esso, in effetti, grazie ad alcune circostanze fortunate e molti errori da parte dei concorrenti, Microsoft ha costruito la sua supremazia sul mercato del software. Una supremazia tale da far pensare, ai neofiti dell informatica, che il computer sia solo Windows, Office, Internet Explorer e poco altro, un 2 8

9 Introduzione ordine di idee adottato anche da enti ufficiali di accertamento delle conoscenze informatiche (si pensi ad ECDL). Questo ha reso difficile diffondere l idea che l informatica non è limitata ai prodotti Microsoft, ma che esistono valide alternative, anche e soprattutto nel campo dei sistemi operativi. Questo motivo e l importanza degli OS nell informatica moderna, di cui si è appena parlato, sono due delle ragioni che hanno portato alla nascita del progetto di Zoo di sistemi operativi (Free Operating Systems Zoo), che ha mosso i suoi primi passi nella primavera del 2004 da un idea di Renzo Davoli. Il termine zoo vuole richiamare la molteplicità di sistemi operativi disponibili e la molteplicità di architetture sui quali essi girano, mentre il termine free richiama sia la libertà di accesso che si vuole conseguire che l uso di software libero. Le altre motivazioni che hanno ispirato il progetto sono, principalmente, la possibilità di sperimentare e quella di imparare l uso di nuovi sistemi operativi, a fini divulgativi ed educativi. Essenzialmente, lo zoo è un sistema per testare sistemi operativi FLOSS (Free/Libre/Open Source Software), utilizzando immagini scaricabili, ossia singoli file contenenti l installazione di un OS, e un software di emulazione adatto a creare macchine virtuali, ossia rappresentazioni di architetture hardware esistenti. Questo lavoro di tesi si propone di descrivere un implementazione dello zoo accessibile tramite World Wide Web, grazie alla quale l utente non sia tenuto a scaricare immagini e software di emulazione sul proprio computer. Il capitolo 2 tratteggia in dettaglio l idea dello zoo e le motivazioni che hanno portato alla sua realizzazione, e dà una panoramica dello scenario dello zoo, ossia i software che implementano parti dello zoo e le alternative ad essi, oltre che altri sistemi esistenti simili allo zoo. Il capitolo 3 descrive l implementazione dello zoo sviluppata per questo lavoro di tesi, denominata FLOZ (Free Live OS Zoo), presentandola dal punto di vista dell utente, del fornitore di accesso che voglia rendere disponibile lo zoo ai propri utenti, e dello studioso che 9

10 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web vuole comprenderne i dettagli architetturali. Il capitolo 4 presenta alcuni possibili sviluppi futuri dello zoo, riguardanti il supporto alla sicurezza, alla rete, alla personalizzazione dei sistemi operativi utilizzabili e alla gestione del carico computazionale. Il capitolo 5 conclude il lavoro, presentando brevemente gli obiettivi raggiunti. 10

11 2 ZOO DI SISTEMI OPERATIVI: IDEA E SCENARIO I hate this place. This zoo. This prison. This reality, whatever you want to call it, I can t stand it any longer. It s the smell, if there is such a thing. I feel saturated by it. I can taste your stink and every time I do, I fear that I ve somehow been infected by it. AGENT SMITH, THE MATRIX L idea centrale su cui questa tesi si incentra è quella di zoo di sistemi operativi. Come dice la parola stessa, si vuole richiamare il concetto di zoo, come insieme di animali. Ed effettivamente, come gli animali di uno zoo, pur essendo tutti animali, tendono ad essere molto diversi tra loro (alcuni sono mammiferi, altri uccelli, altri rettili, altri ancora anfibi), così lo sono i sistemi operativi. È ben noto infatti quanta varietà di caratteristiche contiene la definizione collettiva di sistemi operativi. Le piatteforme hardware sulle quali essi girano variano considerevolmente, sia riguardo ai dispositivi di I/O (tastiere, dispositivi di puntamento, manopole, schermi, indicatori, sistemi sonori e di stampa), sia riguardo ai sistemi di calcolo (CPU), sia riguardo agli eventuali mezzi di memorizzazione (Memorie di massa, RAM, ROM, supporti rimovibili). Variabile è anche l uso che si fa degli OS, da quelli più general purpose utilizzati da PC e Macintosh a quelli di sistemi embedded, PDA, applicazioni speciali (pilotaggio automatico, terapia intensiva). A sua volta, questo influisce sulle singole funzionalità richieste al OS stesso: buoni driver per la grafica piuttosto che un protocollo di comunicazione affidabile, poco spazio occupato piuttosto che capacità di utilizzo real time. Anche gli animali vivono in ambienti diversi, devono fare cose diverse (chi volare, chi nuotare, chi correre), hanno sviluppato il corpo 11

12 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web per servire al meglio il loro scopo (la pelle più spessa per il freddo, la mandibola sporgente per prendere meglio i piccoli pesci volando a pelo d acqua, organi in grado di emettere luce per attirare le prede); dunque il paragone animali sistemi operativi è perfettamente calzante. Altrettanto calzante è il paragone tra lo zoo di sistemi operativi e lo zoo di animali; la caratteristica più interessante di questo paragone, nell ambito di questa tesi, è l esigenza, in entrambi i casi, di ricreare un ambiente variegato, che permetta ad abitanti diversi di convivere in uno spazio ridotto. Come uno zoo di animali può mettere vicine specie molto diverse, che in natura è impossibile trovare nello stesso habitat, uno zoo di OS permette di usare insieme sistemi operativi nati per habitat (ossia architetture hardware e software) che poco o nulla hanno in comune. Il titolo della tesi indica il modo in cui si è scelto di realizzare questo zoo: un supporto di macchine virtuali che consenta l accesso tramite il World Wide Web. Ciò significa che i sistemi operativi dello zoo non saranno installati su macchine reali, ma su macchine virtuali (VM3) che risiedono su server collegati ad Internet o a una rete locale, e che sarà possibile utilizzarli e testarli tramite un Web browser. Le motivazioni per queste scelte sono descritte nella sezione seguente. 2.1 Motivazioni e vantaggi dello zoo Tanti soggetti sono coinvolti nel progetto di zoo di sistemi operativi, dunque sarebbe necessario conoscere le motivazioni di ciascuno. Questa tesi si lega principalmente al lavoro del Free Operating Systems Zoo4, ideato da Renzo Davoli e gestito da Stefano Marinelli, dalla cui homepage si legge questo estratto: The idea underlying FreeOSZoo is that every Human Being should have equal learning rights. With FreeOSZoo, in a matter of minutes, every teacher around the world is able to download a Free Operating System, 3 Da qui in avanti si userà VM (Virtual Machine) per indicare macchina virtuale sia al singolare che al plurale (in italiano)

13 Zoo di sistemi operativi: Idea e scenario together with a large number of Free Software, and use them for teaching purposes on existing computers. Because of the large number of Free Software, probably more than mature projects, FreeOsZoo suits nearly every teaching purposes, from teaching two year old children to giving University courses. In questa presentazione si notano due motivazioni fondanti dello zoo: la didattica e la libertà di sperimentazione. Entrambe discendono da un unica caratteristica dello zoo: rendere il più possibile indipendente l area dove lo zoo è costruito dalle necessità degli animali che lo abitano, ossia, ragionando nell ambito degli OS, rendere indipendente l architettura hardware e software dal sistema operativo che si vuole utilizzare in essa. Un docente non ha più la necessità di usare macchine diverse per installare OS diversi, ma può utilizzarne molti su poche macchine uguali, con un evidente risparmio nell investimento in hardware. E chi vuole provare un sistema operativo nuovo può farlo senza dover partizionare l Hard Disk del proprio computer e riavviarlo ogni volta, ammesso che l architettura del computer sia compatibile con quel OS. Un ulteriore motivazione che ha ispirato il lavoro di questa tesi è il desiderio di creare qualcosa di nuovo, un applicazione che possa essere veramente di aiuto nella conoscenza dell informatica. L esistenza di uno zoo implica l esistenza di più OS, un fatto non necessariamente noto a tutti. Inoltre, la possibilità di provare senza stravolgere la configurazione del proprio computer permette a chi non conosce un sistema operativo di testarlo, e questo aiuta la diffusione di OS poco noti (soprattutto se liberi), dotati magari di ottime funzionalità ma sprovvisti di un supporto di marketing tale da farli conoscere al pubblico. Un altro vantaggio dello zoo è la possibilità di testare il sistema operativo in una sorta di sandbox, un computer virtuale sul quale l utente ha controllo totale, anche se nel computer reale non possiede privilegi di amministrazione. Ciò permette di conoscere meglio quel sistema operativo, personalizzarlo secondo le proprie esigenze, avere 13

14 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web una base di prova per valutare modifiche per un sistema reale. Si pensi, ad esempio, di voler cambiare il proprio GNU/Linux con quello di un altra distribuzione; con lo zoo è possibile provare la nuova distribuzione a parte, per verificare che il cambiamento sortisca i vantaggi voluti, ed in seguito effettuare il passaggio. Si tratta di una potenzialità utile anche dal punto di vista della sicurezza: le conseguenze di errori di amministrazione o attacchi al sistema operativo vengono ridotte, sia a livello hardware che a livello software. L accesso via Web allo zoo aggiunge un vantaggio: la possibilità di testare il sistema operativo riducendo al minimo i requisiti e la configurazione del computer dell utente dello zoo. Come si vedrà nella sezione 3.1, infatti, l uso dello zoo richiederà soltanto una connessione ad Internet e un Web browser con supporto per le applet Java, strumenti reperibili per ormai tutte le architetture hardware e software e di norma non troppo esosi in termini di risorse richieste. Caratteristica fondamentale dello zoo è l essere free, non solo per la possibilità di accedervi con requisiti minimi e senza vincoli, ma anche per l utilizzo di software libero. A parte QEMU Accelerator (vedi ), rilasciato con una licenza che ne consente gratuitamente il libero utilizzo, tutti i componenti utilizzati per lo sviluppo dello zoo e i sistemi operativi di prova sono rilasciati sotto GPL o licenze equivalenti, e lo stesso codice sorgente del progetto realizzato per questo lavoro di tesi è rilasciato sotto tale licenza. Per l autore della tesi, come per il relatore, l utilizzo e la promozione del software libero sono molto importanti, in quanto il software libero garantisce di sapere esattamente cosa fa l applicazione che si sta utilizzando e difende da software malevoli, oltre a permettere a chiunque di partecipare e migliorare le applicazioni stesse. In definitiva, uno zoo di sistemi operativi è una possibilità offerta a chiunque abbia interesse, per qualsiasi scopo, a provare soluzioni informatiche diverse, riducendo il più possibile i costi necessari in tempo e risorse hardware, ed un modo per diffondere conoscenza di prodotti alternativi. 14

15 Zoo di sistemi operativi: Idea e scenario Prima di proseguire la discussione di questo sistema, è bene però soffermarsi sul panorama dell emulazione informatica, la sua storia, la classificazione ed alcuni esempi, e su altri esempi di sistemi che, come quello oggetto di questa tesi, permettono l utilizzo tramite Internet di sistemi operativi diversi. Questo permetterà, tra l altro, di esaminare diffusamente i progetti software che costituiscono l ossatura di questo lavoro di tesi. 2.2 Storia e classificazioni dei sistemi di emulazione Il concetto di macchina virtuale si presta a numerose definizioni, a causa della eterogeneità di sistemi classificabili con questo nome. Sicuramente si tratta di applicazioni, sistemi software, dunque qualcosa già di per sé virtuale, impalpabile. Il fatto che si parli di macchina, termine che da solo richiama invece qualcosa di reale e palpabile, dà già una prima idea di ciò di cui si sta parlando: un software che permette di emulare un dispositivo reale. L idea può essere in realtà ampliata, in quanto non è necessario che sia emulato un dispositivo esistente. Nel lavoro di tesi di Ludovico Gardenghi e Andrea Gasparini [Gar2006, Gas2006], che ha fornito gran parte del materiale sul quale il prosieguo di questo capitolo si basa, a causa dell ambito comune al quale si fa riferimento, si usa la seguente definizione di VM: Un software che crea fra il computer e l utente finale un ambiente all interno del quale è possibile eseguire software Questa definizione è interessante perché focalizza esattamente la peculiarità della VM, che è appunto quella di creare, all interno di un altra macchina (reale o meno) un ambiente separato, non necessariamente a conoscenza della macchina esterna, nel quale eseguire software. L idea di virtualizzazione si lega a doppio filo con quella di astrazione. Il concetto di astrazione è un fondamento 15

16 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web dell informatica, in quanto ogni sistema di calcolo è una pila di sottosistemi, o livelli di astrazione, collegati tra loro da interfacce ben definite e standardizzate. Un tipico esempio di astrazione è quello della memorizzazione di files. Il supporto di archiviazione è composto da indirizzi oppure da settori, cilindri e facciate; al di sopra di questo, il file system crea un primo livello di astrazione fatto da unità di allocazione (blocchi o cluster) e, ancora al di sopra, queste unità vengono raggruppate in file e i file in cartelle. I file non dipendono dal supporto di archiviazione, ma solo dal livello loro sottostante, ossia le unità di allocazione e la loro organizzazione; chi usa i file, a sua volta, non si dovrà curare di come essi sono memorizzati nel file system. La differenza fra astrazione e virtualizzazione [SmiNai2005] è che la prima, dovendo implementare interfacce ben definite, non permette a livelli progettati per un interfaccia di essere eseguiti su un altra; per esempio, il set di istruzioni di un processore (Instruction Set Architecture, ISA) ed il sistema operativo sono l interfaccia dei programmi compilati, i quali non possono, di norma, essere eseguiti su altre ISA o altri OS. I sistemi di virtualizzazione aggirano questo limite, creando nuove interfacce che vengono tradotte in modo da potersi appoggiare a quelle già esistenti. Con la virtualizzazione è possibile eseguire applicazioni o sistemi operativi compilati per una certa architettura in un altra, far comportare un certo dispositivo di input/output come un altro, far apparire come memoria RAM porzioni di memoria di massa, mettere un hard disk dentro ad un singolo file. A seconda dei casi, il livello di astrazione messo a disposizione dalla macchina virtuale può essere un nuovo livello, che normalmente si collocherebbe al di sotto di quello reale (è il caso delle rappresentazioni su file di hard disk), oppure la ridefinizione di un livello esistente (come nell emulazione di dispositivi). Sembra dunque ora ben chiara l eterogeneità intrinseca del termine macchine virtuali. Sarà quindi necessario, dopo un introduzione storica, fornire degli schemi di classificazione e citare alcuni esempi, soffermandosi in particolare su quelli più pertinenti a 16

17 Zoo di sistemi operativi: Idea e scenario questo lavoro di tesi Breve storia Il primo esempio di macchina virtuale proposta è stato il sistema VM/370 di IBM, presentato negli anni 60 [Bar1973, Cre1981]. Il panorama dei sistemi di calcolo vedeva allora l uso di macchine da alte prestazioni (per l epoca), ad alti costi, vendute in un unico pacchetto (hardware, software, servizi) da aziende come IBM, per scopi di calcolo, ricerca scientifica ed altro. Era necessario, per motivi appunto di costo (oltre che di ingombro), condividere una singola macchina tra molti utenti, e per fare ciò erano stati progettati sistemi operativi con politiche adatte a tale condivisione, gli OS time sharing. VM/370 viene definito un sistema di time sharing di seconda generazione, in quanto quelli precedenti, pur potendo eseguire operazioni in background, non presentavano un interfaccia dedicata per ogni utente. Il sistema era composto di tre parti: CMS (Conversational Monitor System), un OS dedicato per ogni utente, CP (Control Program) il sistema che ha il controllo della macchina reale e fornisce l interfaccia ai CMS, e RSCS (Remote Spooling and Communications System), un sistema per la gestione delle comunicazioni e delle code di esecuzione tra i vari CMS. CP fornisce a CMS una rappresentazione dell hardware identica alla macchina reale, ma in modo che ogni CMS non veda le altre e non possa entrare nello spazio ad esse riservato. VM/370 era dunque una VM pensata per dare ad ogni utente una copia esatta della macchina, garantendo compatibilità del software, isolamento e prestazioni dello stesso ordine di grandezza di una macchina reale. A metà degli anni 90, mentre ormai l idea iniziale di VM/370 era stata superata, grazie anche al successo dello standard PC e al conseguente abbassamento dei prezzi dell hardware, da sistemi operativi multiutente che non necessitavano più di macchine virtuali, l idea di virtualizzazione trovò un nuovo sbocco nei linguaggi di programmazione. Quello di creare programmi che funzionassero sul 17

18 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web maggior numero di architetture possibili era un progetto tentato già nel 1978, quando l University of California di San Diego aveva creato un sistema operativo, UCSD p System5, i cui applicativi erano scritti in Pascal (UCSD Pascal, la versione più usata all epoca) e compilati in un codice intermedio tale da poter essere eseguiti direttamente su qualsiasi architettura per la quale esistesse una versione di p System. Se alla fine degli anni 70 l interesse per un linguaggio di programmazione portabile era principalmente accademico, nel 1994 l affermazione del World Wide Web portava con sé esigenze per le quali quel tipo di linguaggio era decisamente un ottima soluzione. La Sun creò così [KMM1999] Java, che con il Web condivideva, appunto, l indipendenza dal software sottostante. Essendo Java parte integrante del lavoro di questa tesi, si rimanda alla sezione per notizie più dettagliate. Un nuovo interesse per un idea di macchina virtuale simile a quella di VM/370 si è riacceso a fine anni 90, con l introduzione di tecnologie [Ros2004] pensate non solo per l ambito professionale e basate su server, ma anche per l esecuzione su computer desktop. In questi casi, il gestore di macchine virtuali (Virtual Machine Monitor o VMM) non è più un software leggero direttamente comunicante con l hardware reale, come accadeva con CP, ma un applicazione che gira come normale processo all interno di un OS qualsiasi (questo tipo di emulazione viene definito hosted). Inoltre le possibilità di virtualizzazione si sono moltiplicate, da quelle più generiche che implementano intere macchine reali a quelle che emulano sistemi operativi, o singole periferiche Classificazione delle macchine virtuali Come accennato, tante sono le possibilità ad oggi disponibili di emulazione, per questo si rende necessario definire una tassonomia. 5 p System sarà uno dei tre OS supportati da IBM per il suo PC, insieme a CP/M 86 di Digital Research e DOS di Microsoft. 18

19 Zoo di sistemi operativi: Idea e scenario Inoltre, la varietà è tale che possono essere usati criteri diversi per classificare, ottenendo quindi tassonomie diverse. In questo paragrafo verranno esaminate due possibilità, sufficientemente diverse tra loro per permettere una visione di tutte le caratteristiche essenziali dei sistemi di emulazione. La prima, proposta da Renzo Davoli [Dav2004a] per il progetto Virtual Square, si focalizza sulla tecnologia della VM, tralasciando i possibili usi, mentre la seconda, proposta da James E. Smith e Ravi Nair [SmiNai2005] pone l accento sul tipo di virtualizzazione come appare all utente, non considerando gli aspetti implementativi delle varie soluzioni La classificazione secondo Virtual Square Virtual Square è stato concepito come un punto di raccolta e promotore di tecnologie dedicate alla virtualizzazione di ambienti informatici, sistemi operativi o reti, creato per permettere modifiche dinamiche e trasparenti alla rete e alle sue risorse [Dav2005]. Nel sito [Dav2004a] è stata anche introdotta una classificazione sulla virtualizzazione, che distingue innanzitutto tra macchine virtuali e reti virtuali. Le prime sono analizzate sotto tre aspetti. Comunicazione tra VM e computer reale. Il primo aspetto esamina come la macchina virtuale si interfaccia all architettura sottostante, o quale sistema crea il livello di astrazione usato dalla macchina virtuale. Sono distinguibili due gruppi principali: Virtualizzazione dell architettura del processore: in questo caso viene costruito come livello di astrazione un intero ambiente hardware, o comunque un interprete di tutte le istruzioni macchina eseguite dal sistema operativo o dalle applicazioni da esso controllate. In questo modo si possono creare VM complete, e portare in ambienti eterogenei interi sistemi operativi con le applicazioni loro dedicate, ad esempio portare un OS in un architettura per la quale non è stato progettato. 19

20 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web System call trapping: il livello di astrazione è posto più in alto, in quanto si intercettano le chiamate di sistema (system calls), ossia l interfaccia di programmazione implementata dal sistema operativo per eseguire operazioni privilegiate (gestione file, IPC, rete...). Si possono ad esempio mappare le system call del sistema emulato (guest) con le corrispondenti del sistema reale (host) manipolando parametri di chiamata e valori di ritorno secondo le esigenze di entrambi. Questi sistemi sono di solito più performanti di quelli basati su virtualizzazione dell architettura, ma meno portabili, sia perché i meccanismi di intercettazione delle system call variano a seconda dell host OS, sia perché di solito servono versioni ad hoc del target OS, sia perché ovviamente l interfaccia di system call varia da sistema operativo a sistema operativo. Completezza della virtualizzazione. Si vuole qui misurare quanto dell hardware reale viene emulato dalla VM. Sono identificabili tre gruppi: Solo virtualizzazione del processore: tutte le risorse di sistema sono accedute dal sistema host, mentre il solo processore è emulato. VM parziale: i programmi vengono eseguiti dal processore host, alcune parti del sistema reale sono virtualizzate senza la necessità di avviare un sistema guest. Virtualizzazione completa: CPU e periferiche sono emulate; è necessario un OS guest per eseguire i programmi. In generale, meno si emula e maggiori prestazioni si ottengono, ma un alto grado di virtualizzazione permette più separazione tra gli ambienti, il che di norma vuol dire anche maggior sicurezza. Invasività nell OS host. Indica quanto il sistema operativo reale è influenzato dall uso del sistema di virtualizzazione, sia riguardo alle modifiche che ai permessi richiesti: 20

21 Zoo di sistemi operativi: Idea e scenario Accesso a livello utente: chiunque può eseguire il sistema di virtualizzazione, che quindi opera senza accessi privilegiati né modifiche alla macchina reale. L utente può risultarne limitato, ma la separazione degli ambienti è maggiore e può garantire più sicurezza. Accesso a livello superutente: l esecuzione è riservata a chi possiede privilegi amministrativi sulla macchina reale. Questo può essere un buon compromesso, permettendo alla VM un maggiore controllo e dando quindi più possibilità d uso all utente, mantenendo comunque un buon livello di sicurezza. Possono sorgere problemi nel caso di imperfezioni nel codice della VM, e comunque si tratta di un sistema poco adatto da far usare a utenti non affidabili. Patch al kernel: la VM richiede una modifica al sistema operativo, di solito attraverso l uso di patch binarie applicate al kernel dello stesso. Queste patch di solito danno un notevole incremento di prestazioni alla VM, ma sono molto invasive e richiedono privilegi di superutente per essere installate; è comunque possibile che, dopo l applicazione della patch, la VM possa essere utilizzata a livello utente, mantenendo il grado di sicurezza indicato al primo punto (ma ancora con i rischi derivanti da possibili bug nelle patch). Riguardo alle reti virtuali, la classificazione si limita all invasività del sistema emulato, con gli stessi criteri appena enunciati. Come detto, questa classificazione ha un punto di vista squisitamente tecnico, mirante soprattutto a rilevare le caratteristiche implementative dei vari sistemi di emulazione più che le loro peculiarità per l uso pratico. Quest ultimo punto di vista è invece rintracciabile nella tassonomia di Smith e Nair La classificazione secondo Smith e Nair Per capire questo tipo di classificazione [SmiNai2005] bisogna 21

22 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web prima chiarire il significato di macchina (e, di conseguenza, di macchina virtuale) dal punto di vista di un processo e dal punto di vista del sistema. Per un processo la macchina è lo spazio logico di memoria ad esso associato, l insieme di istruzioni e registri del processore utilizzabili e l interfaccia del sistema operativo verso l hardware; tutto l I/O è mediato e filtrato da system call messe a disposizione dai livelli software sottostanti. Per il sistema operativo e le applicazioni, considerati nel loro insieme, la macchina è definita unicamente dall hardware: l interfaccia verso il basso è il solo set di istruzioni del processore. Definita questa differenza si stabilisce subito uno dei due criteri adottati da Smith e Nair per la loro classificazione: la differenza, appunto, tra macchina virtuale per processo (process VM) e macchina virtuale per sistema (system VM). Nel primo caso viene fornito il solo ambiente necessario all esecuzione diretta del processo, come indicato sopra; nel secondo caso si emula l intero ambiente necessario all esecuzione di un OS e delle sue applicazioni. L altro criterio adottato dai due autori è ortogonale al primo, e riguarda il fatto che la VM modifichi il comportamento del livello su cui si appoggia oppure utilizzi direttamente le funzioni della macchina reale. Nel primo caso si può realizzare una VM coerente in struttura con la macchina reale, alla quale aggiungere proprietà addizionali quali sicurezza o isolamento (è lo scenario di VM/370, ad esempio). Nel secondo caso invece si vogliono eseguire applicazioni scritte per altre architetture, dunque lo scopo è quello di usare tali applicazioni in piatteforme hardware diverse oppure creare framework per codici portabili (come avviene in Java Virtual Machine e sistemi affini). 2.3 Esempi di emulazione Viene ora presentata una carrellata di sistemi di emulazione. Questa carrellata ha due scopi principali: mostrare con esempi concreti 22

23 Zoo di sistemi operativi: Idea e scenario tutte le possibilità della virtualizzazione, e soffermarsi su quei progetti che hanno diretta attinenza con questo lavoro di tesi. Dunque le tecnologie trattate più diffusamente saranno QEMU, VDE e Java, mentre le altre verranno presentate per confronto e per catalogazione nelle tassonomie appena descritte Macchine virtuali complete Una prima classe di esempi di VM che si vedrà è quella delle macchine virtuali complete ; con questa denominazione si intendono VM che permettono la virtualizzazione di un completo calcolatore di una determinata architettura. Questa tipologia di macchina è usata per eseguire un sistema operativo completo e un certo numero di applicazioni. Esistono varie implementazioni di VM di questo tipo; ne vengono qui citate alcune, senza pretesa di completezza e lasciando più spazio a quelle più usate o considerate più interessanti. Come detto, maggiore spazio verrà dato a QEMU, software direttamente impiegato in questo lavoro di tesi QEMU6 È forse il progetto più completo tra quelli che verranno descritti, in quanto è stato progettato per essere facilmente portato sul maggior numero di hardware possibili e per emulare il maggior numero di architetture possibili. Suo autore è Fabrice Bellard, autore di altri importanti progetti software come FFMPEG, sistema di conversione ed esecuzione multimediale e raccolta di codec audio/video, e Linmodem, progetto per il supporto dei modem software (anche detti winmodems) in Linux. QEMU è stato sviluppato per Linux e altri sistemi POSIX, ma esistono port per Mac OS X e Windows; le CPU host supportate correttamente sono, al momento, x86, x86_647 e PowerPC. La sua Si ricorda che x86_64 identifica le CPU AMD64 di AMD e quelle Extended Memory 64 Technology (EM64T) di Intel. Le CPU IA64 (come Intel Itanium) non rientrano in questa categoria. 23

24 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web classificazione è multipla, in quanto QEMU ha differenti modalità di esecuzione, che implicano caratteristiche implementative e d uso diverse. Innanzitutto è bene descrivere le caratteristiche generali. QEMU effettua [Bel2006] traduzione dinamica dell ISA del processore emulato, generando una nuova istruzione per ogni comando della CPU guest e riutilizzandola all occorenza. Per superare la lentezza intrinseca dei traduttori dinamici, QEMU utilizza alcuni trucchi di programmazione. Le istruzioni dell architettura emulata (es. x86) vengono suddivise in operazioni più semplici, ciascuna implementata da codice C. Nella prima parte della compilazione è prodotto un programma (dyngen) che nelle successive fasi prende i file oggetto ottenuti dal codice C delle istruzioni e costruisce un generatore dinamico di codice che concatena le singole operazioni per produrre funzioni. Le operazioni semplici possono prendere parametri costanti, e vengono compilate generando rilocazioni del codice ELF. In questo modo dyngen può localizzarle e produrre nel generatore dinamico il codice necessario a risolverle. Questo permette a QEMU di non essere più difficile da portare verso altre architetture rispetto a un linker dinamico. Altre ottimizzazioni sono usate. Lo stato della CPU virtuale è mantenuto in variabili statiche di registro, e vengono ottimizzati i codici di condizione, l allocazione dei registri, lo stato della CPU emulata. I blocchi di codice tradotto più recentemente usati sono posti nella cache ed eventualmente concatenati direttamente. L MMU è emulata, quando possibile, tramite la system call mmap() e quindi accedendo alla MMU del processore reale; QEMU implementa anche delle MMU software nei casi in cui l OS guest potrebbe accedere a memoria riservata dell OS host. QEMU può, tra l altro, emulare più di una CPU (fino a 255 su x86). Come detto, esso supporta due modalità di esecuzione: User Emulation: riguarda l esecuzione di processi Linux su OS Linux. In questo caso viene effettuata (per velocizzare il 24

25 Zoo di sistemi operativi: Idea e scenario sistema) l intercettazione delle system call, convertendo i parametri secondo le esigenze delle CPU (reale e virtuale) utilizzate. Si tratta quindi di un emulazione del solo processore ma tramite trap delle system call, e riguardo alla tassonomia di Smith Nair è una VM di processo che modifica il livello al quale si appoggia. Le CPU per le quali è attualmente supportata l emulazione utente sono x86, PowerPC, ARM, SPARC e MIPS. System Emulation: è l emulazione completa di CPU e periferiche per l esecuzione di un OS guest. Si tratta quindi di una vera virtualizzazione del processore e completa, una VM di sistema con accesso diretto alle risorse della macchina reale. L emulazione di sistema è attualmente supportata per le stesse CPU per le quali è disponibile l emulazione utente, con l aggiunta di x86_64. L invasività è bassa, in quanto tutto il codice ISA prodotto è eseguito in user mode, e lo stesso QEMU non richiede privilegi di super utente. Esiste però un modulo aggiuntivo proprietario prodotto dallo stesso Bellard, chiamato QEMU Accelerator Module o KQEMU, distribuito come modulo per il kernel Linux 2.4 e 2.6 e, a livello sperimentale, per FreeBSD e come servizio per Windows NT (2000, 2003, XP). Questo modulo velocizza nettamente l esecuzione in system emulation quando sia la CPU host che quella guest sono x86 (o x86_64). Una volta installato, infatti, QEMU può eseguire (interfacciandosi col modulo tramite il dispositivo speciale /dev/kqemu) le istruzioni user mode della CPU guest direttamente su quella host, senza alcuna traduzione. L aumento di performance è rilevante: se il rapporto tra la velocità di un applicazione su macchina reale e la velocità su QEMU è tra 5 e 10, con KQEMU si scende a 1 2. La versione 1.3.0pre7 di KQEMU ha introdotto un ulteriore miglioramento, la virtualizzazione completa, che permette di eseguire anche tutto il codice system mode della CPU guest come codice user della CPU host, con un minimo di traduzione dovuto proprio alla necessità di eseguire codice system in user mode, 25

26 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web per garantire sicurezza. In questo caso, salvo rare eccezioni, la velocità del OS emulato è davvero identica a quella del sistema operativo reale. La virtualizzazione completa non funziona con tutti gli OS, in quanto KQEMU fa delle assunzioni sul codice system mode eseguito dal sistema guest, assunzioni non sempre valide. Nella system emulation, QEMU carica delle immagini, singoli file contenenti rappresentazioni di interi hard disk o immagini ISO di CD/DVD. Le immagini possono essere rappresentazioni dirette (raw) oppure formati speciali come vmdk (usato da VMware), Bochs (usato dall emulatore omonimo, forse il software al quale QEMU si è maggiormente ispirato), Copy on Write (o cow, usato da User Mode Linux), cloop (immagini CD ROM compresse, come quelle della distribuzione Linux Knoppix) o qcow, versione speciale di Copy on Write specificamente progettata per QEMU, che supporta la codifica dei dati con AES8 e la compressione tramite zlib9. È possibile avviare le immagini in modalità snapshot, in modo che le modifiche siano perse al termine di ogni esecuzione. QEMU supporta due tipi di output: quello locale, che utilizza librerie proprie del sistema operativo (come SDL in Linux), e quello remoto tramite un server VNC incluso. Di quest ultimo si tratterà diffusamente nel paragrafo 3.3.2, in quanto è parte integrante dello zoo. Tastiera e mouse sono emulati direttamente nel sistema, e nel caso di output locale il puntatore del mouse dev essere bloccato nella finestra, per avere effetto nell OS guest. Le altre periferiche supportate dalla system emulation di QEMU sono: i440fx host PCI bridge e bridge PIIX3 PCI ISA Scheda video Cirrus CL GD 5446 PCI VGA o VGA card fittizia con estensioni VESA di Bochs10 (a livello hardware, comprese le modalità non standard) Due controller IDE PCI per supporto delle immagini HDD

27 Zoo di sistemi operativi: Idea e scenario e CD/DVD Controller Floppy disk per il supporto delle immagini FDD Schede di rete: NE2000 (PCI e ISA), Realtek RTL8139, SMC91c111, Lance Porte seriali Schede audio: Creative SoundBlaster 16, ENSONIQ Audio PCI ES1370, Adlib(OPL2) con chip compatibile Yamaha YM3812 Controller USB PCI UHCI e hub USB virtuale Discorso a parte merita il supporto di rete. Oltre al modello di scheda da emulare (necessario in quanto non tutti gli OS supportano lo stesso modello) è possibile specificare il MAC address della scheda stessa e collegarla ad una VLAN (Virtual LAN); tutto questo è specificato dall opzione -net nic. Le altre opzioni -net specificano a cosa collegare la VLAN: -net user crea uno stack TCP/IP in user mode, usando una versione modificata del codice di Slirp11, un emulatore di connessioni SLIP/PPP su terminale scritto da Danny Gasparovsky. Lo stack comprende anche l instradamento delle query DNS verso il DNS di default dell host OS, e un server DHCP che fornisce un indirizzo IP nella subnet , con come gateway/dhcp e come DNS. Per maggiori informazioni sul meccanismo di gestione delle connessioni, si legga la descrizione di slirpvde nella sezione , il cui codice è in gran parte derivato da questo. -net tap collega il NIC ad un interfaccia TUN/TAP12, eventualmente specificandone il file descriptor, il nome e uno script per la configurazione dell interfaccia stessa. -net socket collega il NIC ad uno UNIX socket, sia esso un file, una porta TCP o UDP. Nel caso di TCP è possibile effettuare

28 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web connessioni mettendo il NIC in ascolto o connettendosi ad un altro già presente, se si usa UDP si può specificare una porta per il multicast. Il multicast adottato è compatibile con User mode Linux. -net none non emula alcun NIC. Se l opzione -net non è specificata, il default è -net nic -net user. QEMU è un progetto open source e raccoglie attorno a Bellard un ampio gruppo di sviluppatori. Questo rende veloce sia la risoluzione dei problemi sia l aggiunta di nuove funzionalità, ed ha permesso il test di una ormai vastissima gamma di sistemi operativi guest13. Per questi motivi, e per il supporto a VNC, QEMU è stato scelto per la realizzazione di questo progetto. Altro emulatore simile a QEMU è il già citato Bochs, dal quale QEMU ha tratto molti elementi utili per lo sviluppo, che emula processori x86 e x86_ VMware14 VMware è un progetto proprietario che racchiude una struttura decisamente più complessa delle altre descritte. VMware permette la virtualizzazione di macchine complete su architetture x86; mantiene quindi la stessa interfaccia fra i sistemi host e guest, che possono eseguire sistemi operativi Microsoft oppure Linux [VMW2005a, VMW2005b]. VMware è distribuito in varie versioni, le più interessanti delle quali sono GSX server ed ESX server. Ciò che cambia fra queste versioni è la tecnologia usata per astrarre la macchina virtuale. Nel primo caso serve un sistema operativo host che contenga il GSX server come sua applicazione, nel secondo caso invece la VM lavora direttamente sull hardware senza bisogno di un sistema operativo, similmente ai sistemi di paravirtualizzazione descritti nella sezione Una lista è reperibile presso

29 Zoo di sistemi operativi: Idea e scenario VMware è distribuito con una serie di strumenti per l amministrazione delle VM; questo ne fa un prodotto interessante per l utilizzo in grosse realtà commerciali o da parte di utenti poco esperti. Il fatto che sia distribuito come prodotto commerciale a codice chiuso non ne permette, però, uno studio approfondito. VMware permette l accesso diretto alle risorse hardware che riconosce nella macchina reale, cercando di ottenere un compromesso tra la virtualizzazione vera e propria e una sorta di paravirtualizzazione per alcuni dispositivi, il che rende nel complesso la macchina virtuale piuttosto efficiente. Altri punti di interesse in questo progetto sono la possibilità di personalizzare l hardware della VM, decidendo il tipo di periferiche ed il numero dei processori, in maniera simile a QEMU, e la presenza di un virtual infrastructure layer, che permette di unire più macchine reali facendole apparire come una sola alla VM, consentendo tra l altro lo spostamento a caldo del guest tra host diversi senza interromperlo Microsoft Virtual PC15 e Virtual Server16 Sono due versioni, una orientata all uso personale e una pensata per l utilizzo su server, del sistema di virtualizzazione Microsoft. In entrambi i casi il prodotto, da installare su un sistema Windows esistente, fornisce emulazione dell hardware (senza traduzione a livello di ISA, in quanto sia host che guest hanno architettura x86) e consente la creazione di macchine virtuali che possono comunicare con l esterno tramite un architettura di rete virtuale. Si tratta quindi di system VM che si appoggiano al livello applicativo sottostante. Le uniche differenze apparenti (si tratta di un prodotto chiuso del quale sono disponibili poche informazioni tecniche [Hon2003, Mic2005]) fra Virtual PC e Virtual Server sembrano riguardare la scalabilità e la presenza di emulazione per hardware usato in ambito server

30 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web PearPC17 Passando al mondo Apple, PearPC è un emulatore di architettura PowerPC e si dichiara architecture independent. Attualmente è in grado di funzionare sia su macchine little endian che su macchine big endian, con sistemi operativi POSIX X11 (Linux e altri) oppure Windows. L emulazione dell hardware è completa e il degrado di prestazioni notevole (da un quindicesimo a un cinquecentesimo delle prestazioni native); i sistemi operativi guest testati sono Linux/PowerPC, Darwin, MacOS X e alcuni BSD. PearPC è eseguibile direttamente come utente non privilegiato, anche perché non è possibile sfruttare direttamente l hardware reale viste le notevoli differenze di struttura Mac on Linux18 A differenza di PearPC, Mac on Linux è pensato unicamente per eseguire, su Linux per PowerPC, OS scritti per PowerPC. Si tratta di virtualizzazione a livello di sistema ma, come è intuibile, non viene effettuata nessuna trasformazione del set di istruzioni, essendo OS host e guest sistemi scritti per PowerPC. Mac on Linux richiede il caricamento di un modulo nel kernel ed è per questo di media invasività (richiede l intervento del superutente per configurare il sistema) ma, in compenso, riesce a ottenere prestazioni più che buone, soprattutto se paragonate a PearPC. Il supporto per i sistemi guest non è completo e, per esempio, alcune versioni recenti di MacOS X non sono ancora supportate, perché benché l hardware non sia emulato, è comunque necessario virtualizzarlo completamente per evitare conflitti fra i due (o più) sistemi operativi in concorrenza per accedervi Macchine paravirtuali complete Un sistema che attualmente sta riprendendo mercato tra le macchine virtuali è quello della cosiddetta paravirtualizzazione. Il

31 Zoo di sistemi operativi: Idea e scenario termine indica un particolare tipo di virtualizzazione: si tratta di VM complete che non traducono nessuna interfaccia ISA o istruzione. Il monitor delle macchine virtuali si limita, infatti, a creare uno strato minimale per assicurare la gestione delle singole VM e un buon isolamento, in modo molto simile al già discusso VM/370. Entrambi i casi descritti di seguito si occupano solo di separare i flussi di I/O e gestirli correttamente. Le varie istanze delle VM si interfacciano a basso livello con il monitor, che presenta loro un hardware virtualizzato molto simile, ma non identico, a quello reale. Per questo motivo, un requisito dei sistemi di paravirtualizzazione è solitamente il modificare e ricompilare (almeno) il kernel del sistema operativo, che dovrà supportare l architettura virtuale mostrata dal monitor e non quella reale dell hardware. Il monitor si trova al livello software più basso possibile: tuttavia, l interesse per questo meccanismo di virtualizzazione è tale da avere spinto i maggiori produttori di CPU a integrare nei processori di prossima generazione set di istruzioni specifiche per il supporto alla paravirtualizzazione. In particolare, Intel ha lanciato la tecnologia VT [Int2005], già disponibile sui alcuni modelli di Core Solo, Pentium Extreme, Pentium D, Pentium 4 e Xeon, mentre AMD ha da poco rilasciato le specifiche di IOMMU, anche noto come Pacifica [AMD2006], pensato principalmente per i processori Opteron. I processori attuali (specialmente della famiglia x86) richiedono sforzi notevoli da parte del monitor per garantire allo stesso tempo isolamento, prestazioni e trasparenza verso l architettura reale. Per esempio, è rischioso consentire a un sistema operativo in una VM l esecuzione in modalità ring 0 (come avviene normalmente), poiché così avrebbe i privilegi per poter escludere il monitor dal riprendere il controllo dell hardware. I sistemi di paravirtualizzazione attuale infatti richiedono la modifica del sistema guest per consentirne l esecuzione anche con permessi più ridotti. L idea che sarà sviluppata nei nuovi processori è quella di introdurre un nuovo stato, utilizzabile dal monitor per sostituire 31

32 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web rapidamente un sistema operativo con un altro e permettendone l esecuzione efficiente, senza compromettere la sicurezza o l isolamento delle VM. Di seguito sono due trattati due esempi di macchine paravirtuali Xen19 Si tratta di un progetto patrocinato da IBM, che detiene probabilmente il primato di efficienza per le VM tra quelle realmente utilizzabili (il progetto Denali è più efficiente ma non utilizzabile in pratica). Xen si basa su una struttura simile a un microkernel: contiene solo il minimo indispensabile per poter gestire le macchine virtuali guest. In particolare Xen non supporta direttamente tutto l hardware della macchina, ma si appoggia ai driver dell OS della prima macchina virtuale ad essere eseguita: l OS in questione viene definito Domain 0 [BDF+2003]. Attualmente alla release 3, Xen genera sempre maggior interesse in quanto supporta da poco (come VMWare) la migrazione a caldo degli ambienti virtuali: una macchina virtuale può migrare da una macchina reale a un altra che abbia Xen senza che il sistema virtualizzato si renda conto del passaggio. Riguardo alla tassonomia Smith/Nair, Xen si pone come macchina completa che mantiene le interfacce del sistema host. Secondo la classificazione VirtualSquare, è un sistema al maggior livello di invasività (richiede patch e ricompilazione di tutti gli OS guest e richiede un livello addizionale al di sotto del kernel host) Denali20 È il precursore di Xen, definito come un isolation kernel, ossia un kernel progettato per isolare gli ambienti virtuali che girano su di esso. La sua architettura di virtualizzazione consta di tre parti: instruction set, memory unit, I/O architecture [WSG2002a, WSG2002b]

33 Zoo di sistemi operativi: Idea e scenario L instruction set virtuale di Denali è stato progettato per fornire prestazioni e semplicità; consiste in un sottoinsieme dell ISA x86, in modo da poter eseguire, nella maggior parte dei casi, l istruzione direttamente sul processore reale con ovvio guadagno di prestazioni. Per i problemi di sicurezza discussi sopra, certe istruzioni devono essere catturate e gestite dal monitor di Denali; questo obiettivo è raggiunto tramite riscrittura dei binari e tecniche di protezione della memoria. La memory unit si occupa dell isolamento della memoria delle singole macchine virtuali, e il sistema di I/O espone un interfaccia simile alla normale x86, ma anche in questo caso semplificata per quello che riguarda la gestione. Diversa è, invece, la gestione degli interrupt, per migliorare il supporto e l efficienza delle macchine virtuali: gli interrupt vengono ritardati e accodati per essere consegnati a una VM solo quando questa è effettivamente in esecuzione. Operativamente il kernel Denali si occupa del multiplex della CPU tra le macchine virtuali, realizzando quindi uno scheduler a livello di ambiente virtuale. I risultati sui test di prestazioni svolti dagli sviluppatori mostrano che Denali è in grado di gestire un elevatissimo numero di macchine virtuali: disponendo di sufficienti risorse di CPU e memoria questo numero raggiunge l ordine delle migliaia. Il prezzo per trarre vantaggio da queste possibilità è la forzata ricompilazione di tutti gli applicativi racchiusi nella macchina virtuale. Questo implica un grado di invasività ancora maggiore rispetto a quella di Xen, che in pratica ha decretato il rifiuto di Denali da parte del mercato. Nonostante questo il progetto risulta fondamentale, essendo il primo ad aver utilizzato la tecnica della paravirtualizzazione Virtualizzazione del sistema operativo Si passano ora a discutere le macchine virtuali applicate a livello di processo, che mostrano cioè l interfaccia di un sistema operativo alle applicazioni guest. Questi emulatori sono caratterizzati dalla stretta dipendenza dall OS virtualizzato, quindi sono di solito meno portabili 33

34 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web rispetto alle VM complete. Lo stesso termine virtualizzazione assume più significati e sfumature in questo ambito rispetto a quello dell emulazione hardware, in quanto si alza il livello di astrazione sul quale l emulazione è applicata. Per questo motivo, gli esempi qui presentati mostreranno caratteristiche anche molto differenti tra loro, pur rimanendo nella medesima categoria User Mode Linux21 Lo scopo di UML è rendere possibile l esecuzione di un kernel Linux in modalità utente [Dik2005]. Gli utilizzi più classici di questo sistema sono il kernel debugging, l isolamento di processi, l uso di ambienti diversi senza avere più macchine reali (per esempio per una gestione più flessibile della rete), o per creare delle sandbox (ambienti isolati, all interno dei quali eseguire operazioni potenzialmente pericolose, che non permettano nessuna modifica alla macchina reale). UML realizza l ambiente virtuale modificando il kernel per riuscire a farlo eseguire come un normale processo in user mode; l interfaccia messa a disposizione da UML è quindi quella delle system call, che vengono ridirette al kernel reale piuttosto che direttamente all hardware della macchina. Il tracciamento e la modifica delle system call sono resi possibili dalla system call ptrace(); UML esegue il proprio codice per la syscall e modifica lo stato del processo chiamante per riflettere il risultato della syscall da esso invocata. Lo stesso sistema gestisce anche i segnali e le trap. I dispositivi esterni a UML vengono implementati all interno usando file descriptor attivati da segnali, ai quali corrispondono gli IRQ virtuali dei processi emulati. La memoria fisica è implementata tramite file temporanei, gestiti con lo stesso codice per la memoria virtuale usato dal kernel di Linux; gli errori di pagina reale vengono verificati per allocare le pagine virtuali non ancora mappate. Riguardo al file system, infine, UML usa un FS virtuale chiamato hostfs che mappa

35 Zoo di sistemi operativi: Idea e scenario verso il sistema reale le chiamate VFS. Secondo la tassonomia Smith Nair UML è una process VM che modifica il proprio livello di astrazione, senza richiedere modifiche ai programmi reali per essere eseguiti nella VM; secondo Virtual Square, UML è una VM completa, a livello utente, con syscall interception Virtuozzo22 e OpenVZ23 Anche se classificato nella stessa categoria, Virtuozzo è piuttosto differente. Il suo scopo è consentire la presenza di più Virtual Private Server (VPS) Linux su uno o più host; ciascuno di questi VPS è una collezione di applicazioni che condividono lo stesso ambiente virtuale. Ambienti virtuali diversi possono differire per visione del file system, della rete, e per le zone di memoria accessibili [Vir2005]. A differenza di User Mode Linux, tuttavia, Virtuozzo non prevede l esecuzione di copie multiple del kernel: l unica copia attiva è quella dell host e tutti i VPS si appoggiano direttamente ad essa. Il cuore di Virtuozzo consiste in una patch che modifica il sistema operativo aggiungendo la possibilità di creare ambienti separati, all interno dei quali viene ricostruito tutto l albero standard di processi di un sistema Linux (a partire da init fino alle applicazioni utente). Le prestazioni sono ovviamente molto buone (le chiamate attraversano un solo kernel, a differenza di UML, e non c è nessun tipo di traduzione) anche se la flessibilità è inferiore a quella di una macchina UML, che permette per esempio l uso kernel differenti fra host e guest. Virtuozzo si posiziona quindi tra le process VM, con stessa interfaccia ISA, completa e con intercettazione delle system call. L invasività nel sistema host è piuttosto alta anche perché, in effetti, non esiste un vero e proprio sistema guest, quanto una serie di strumenti per creare e amministrare i VPS. Di Virtuozzo, sistema proprietario e completamente chiuso, è stata

36 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web recentemente rilasciata una versione a sorgente aperto, OpenVZ, con alcune funzionalità rimosse, tra le quali la possibilità di unire macchine reali sopra le quali spostare a caldo i VPS. Esiste anche una versione di Virtuozzo per realizzare VPS Windows su host Windows, ma non sarà analizzata qui a causa della scarsa pertinenza di tale OS con l argomento della tesi (si ricorda che il progetto è stato interamente realizzato con software libero e sotto Linux) Linux VServer24 Si tratta di un altro meccanismo (questa volta aperto e completamente open source) utilizzabile per creare server virtuali [Pot2005]. La sua implementazione è descritta come una combinazione di security contexts, routing segmentato, chroot, estensioni alla gestione della quota e altri strumenti standard. L idea di base è quella di associare un contesto a ciascun processo e isolare fra loro i vari contesti. L isolamento avviene in 5 aree: file system (esattamente come con chroot), processi (sono visibili solo quelli del proprio contesto), rete (a ciascun server è assegnato staticamente un indirizzo IPv4), capability del superutente (l utente root di un server virtuale non può fare tutto quello che può normalmente fare su una macchina reale), IPC (possibile solo fra processi dello stesso contesto). Questo in pratica si realizza con un insieme di patch al kernel e alcuni tool esterni di gestione. In nessuna delle cinque aree appena elencate vengono introdotte stratificazioni aggiuntive, dunque le prestazioni si mantengono allo stesso livello di quelle del sistema reale; il prezzo per questo è la scarsa flessibilità e l impossibilità per l amministratore di un server virtuale di avere accesso a tutte le sue normali prerogative (ad esempio, non può modificare la configurazione della rete, che fra l altro supporta la sola versione 4 di TCP/IP). Tuttavia, ben si adatta allo scopo per il quale è stato concepito, ossia creare VPS di rete da usare come server web o mail, che normalmente non richiedono configurazioni speciali. Riguardo alla classificazione, Linux VServer è una process VM

37 Zoo di sistemi operativi: Idea e scenario legata al proprio livello di astrazione secondo Smith Nair, una virtualizzazione completa, invasiva e con intercettazione delle syscall secondo Virtual Square Virtualizzazione a livello di processo Esistono, oltre a quelle descritte finora, altre applicazioni che non sono propriamente definibili come macchine virtuali, in quanto non si pongono completamente tra l applicazione ed il sistema. Esse, comunque, introducono una qualche virtualizzazione nel sistema, dunque rientrano a pieno titolo nell ambito degli emulatori. Lo scopo di tali emulatori, di solito, non è tanto la creazione di un ambiente virtuale da mostrare a utenti o applicazioni, ma di introdurre elementi, magari non inseribili nel sistema reale, per scopi di sperimentazione, debugging, utilità e altro. Si è voluto introdurre una carrellata su queste virtualizzazioni per due motivi: il primo è la presenza di un progetto, VDE, parte integrante di questo lavoro di tesi, che sarà quindi trattato diffusamente; il secondo è la presenza di un altro progetto, View OS/UMView, che introduce un concetto nuovo di virtualizzazione, quello di processo avente una visione completamente personalizzabile e distinta dagli altri dell ambiente nel quale è eseguito. A parte questo progetto più generale, gli altri esempi si focalizzeranno sulla virtualizzazione di rete, con particolare enfasi su VDE, quella di file system, molto usata nella pratica, oltre a un esempio di virtualizzazione del solo processore, Rosetta di Apple. Le reti virtuali vengono utilizzate per molti scopi, dalla sperimentazione di modelli alla creazione di reti locali in ambienti di produzione, dalla separazione di servizi di rete alla creazione di nuove topologie che superino eventuali limiti di reti reali. I file system virtuali vengono anch essi usati per esigenze particolari, per aggirare i limiti dei sistemi operativi o creare più utili astrazioni dei dati. Di solito però non viene creata né una macchina 37

38 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web virtuale né un ambiente separato, ma un unica nuova visione. Questi limiti sono superati nel progetto View OS Virtualizzazione di rete: VDE25 (Virtual Distributed Ethernet) VDE è un progetto ad ampio respiro, studiato per permettere qualsiasi tipo di virtualizzazione nelle topologie di rete. Come suggerisce il nome, lo scopo di questo progetto, fondamento di Virtual Square [Dav2004a] è l emulazione del livello Ethernet in uno stack di rete, implementando i componenti essenziali di tale livello, i cavi e gli switch, oltre che l interfaccia della rete virtuale verso quelle reali o verso altri componenti software. L autore, Renzo Davoli, definisce VDE [Dav2004b] come a Swiss army knife of emulated networks. Sue principali caratteristiche, oltre alla compatibilità Ethernet, sono: VDE è distribuito, ossia non ha una gestione centralizzata, né esiste un componente che abbia una visione globale della rete emulata. Questo garantisce scalabilità. VDE è generale, un architettura di rete virtuale collegabile a OS reali, emulatori, macchine virtuali, altri strumenti di connettività. Il lavorare a livello 2 permette inoltre di costruire un qualsiasi stack di rete al di sopra di esso. VDE è scarsamente invasivo, in quanto può essere eseguito (tranne che per alcune applicazioni) senza alcun privilegio di superutente. Questo è un vantaggio dal punto di vista della sicurezza. VDE è una collezione di applicazioni sviluppate per sistemi POSIX, interamente rilasciate sotto licenza GPL. Verranno ora mostrate le singole applicazioni, iniziando da quelle che implementano i componenti Ethernet, gli switch e i cavi. vde_switch. È l applicazione fondamentale di VDE, alla quale le altre fanno rifermento. Basato sul networking tool di UML, si tratta di

39 Zoo di sistemi operativi: Idea e scenario una implementazione fedele di uno switch Ethernet, ossia un punto di collegamento per più cavi che instrada i pacchetti ricevuti al cavo il cui MAC address corrisponde a quello di destinazione del pacchetto. È anche possibile fare funzionare vde_switch come un repeater (hub) o settarne il numero massimo di porte. Lo switch può essere controllato avviandolo come processo in foreground e premendo Invio per accedere al prompt dei comandi, oppure (se lanciato come demone) con unixterm, altra applicazione di VDE usata per dialogare con i socket di controllo di vde_switch e wirefilter (vedi più avanti). Dal punto di vista implementativo, vde_switch utilizza degli UNIX socket per le connessioni. Vi è un socket di controllo, del quale è possibile settare permessi e gruppo di appartenenza, che può essere un file oppure il collegamento ad un interfaccia di rete TUN/TAP (il cui supporto è presente nei kernel Linux e MacOS X), e viene creato un socket per ogni processo collegato allo switch. L interfaccia TUN/TAP, per collegarsi alla quale vde_switch dev essere avviato con privilegi di superuser, permette la connessione con una macchina reale tramite l interfaccia scelta: è per esempio possibile mettere un server DHCP in ascolto su tale interfaccia, per gestire le richieste provenienti da macchine (virtuali o reali) collegate allo switch. A un vde_switch è possibile collegare, oltre all interfaccia TUN/TAP, macchine virtuali come Bochs, UML, QEMU e MPS (un emulatore MIPS, al cui sviluppo ha collaborato lo stesso Davoli), direttamente o, nel caso di QEMU, con il wrapper vdeq/vdeqemu; VDE cables (vde_plug, dpipe, vde_cryptcab); unixterm, console di gestione dello switch; slirpvde, rigeneratore di connessioni TCP/UDP con supporto DHCP/DNS. vde_plug e dpipe. Sono le applicazioni che permettono di creare cavi virtuali tra switch VDE (VDE cables). vde_plug si collega ad un vde_switch e invia i pacchetti che riceve dallo switch sullo standard output, e i pacchetti che riceve dallo standard input allo switch stesso. dpipe implementa una double pipe, ossia una pipe UNIX a due vie; se nella pipe il primo processo dirige il suo standard output allo standard 39

40 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web input del secondo, nella double pipe anche il secondo processo manda il suo standard output allo standard input del primo. Come per vde_switch, anche per vde_plug è possibile stabilire i permessi dei socket creati e il gruppo di appartenenza. Inoltre si può indicare a quale porta dello switch il plug va collegato. Questa opzione è molto importante perché collegando due plug alla stessa porta è possibile farli lavorare in concorrenza e modificare a caldo le connessioni reali tra switch, proprietà utile per la mobilità. Ad esempio è possibile mantenere una connessione virtuale da un portatile anche se questo passa da una rete wired ad una wireless: si collega il portatile alla nuova rete, si crea il nuovo VDE cable tra i due switch in modo che passi dalla nuova rete e che usi le stesse porte sugli switch, si chiude il vecchio VDE cable e quindi la vecchia connessione reale. dpipe, la cui sintassi di base è dpipe comando1 = comando2 (comando1 e comando2 comprendono le eventuali opzioni) può essere usato per collegare anche più comandi, nel qual caso i comandi con due collegamenti duplicano i loro standard input e output su nuovi file descriptor. È pure possibile collegare ciclicamente input e output di più comandi. vde_plug e dpipe, da soli, permettono di collegare due switch sulla stessa macchina; per collegare due switch remoti serve un qualche sistema di connessione bidirezionale, magari con la possibilità di lanciare comandi da remoto. Due applicazioni che già permettono questo sono netcat e SSH. La prima è insicura, non criptando i dati, mentre la seconda, che utilizza una connessione TCP, può portare a un degrado delle prestazioni se su di essa è incapsulata un altra connessione TCP e la connessione reale perde pacchetti, a causa dell effetto combinato dei meccanismi di recupero di entrambe le sessioni TCP. Ulteriori dettagli su questo problema, oltre che la descrizione di un possibile canale alternativo, vde_cryptcab, che verrà rilasciato con le prossime versioni di VDE, sono reperibili nel paragrafo wirefilter. È uno strumento di corredo a VDE, utile per emulare 40

41 Zoo di sistemi operativi: Idea e scenario reti reali e le problematiche che presentano. Si usa dentro a un VDE cable, con la sintassi dpipe cmd_vde_plug1 = wirefilter [opzioni] = cmd_vde_plug2, e le sue opzioni, impostabili anche a runtime tramite unixterm, permettono di aggiungere, anche asimmetricamente nei due sensi di comunicazione: Perdita di pacchetti (percentuale); Ritardi; Duplicazione di pacchetti (percentuale); Limiti di banda del canale e di velocità di spedizione; Limiti alla coda dei pacchetti e all MTU; Rumore (numero di bit danneggiati per megabyte) Alterazione della politica FIFO del canale. È dunque possibile simulare praticamente qualsiasi caratteristica di una connessione di rete, persino senza alcuna connessione reale; una possibilità molto interessante per sviluppare applicazioni di rete e studiarne il comportamento in qualsiasi condizione, o per fornire servizi con limitazioni predefinite. slirpvde. È un alternativa a TUN/TAP per collegare uno switch alla rete reale. Il codice è preso in gran parte dal supporto di rete utente di QEMU, a sua volta, come detto, estensione di Slirp. In particolare, slirpvde si collega ad un vde_switch, riceve i pacchetti Ethernet, ricostruisce i pacchetti di livello 4 e, nel caso di TCP e UDP, ne incapsula i payload in nuovi pacchetti, tenendo traccia degli IP e delle porte di origine e aprendo porte locali di conseguenza, e li instrada come se fossero pacchetti propri. Alla ricezione di un pacchetto dalla rete reale, slirpvde ricostruisce, in base alle porte, la destinazione nella rete emulata, e genera il pacchetto relativo. slirpvde può inoltre far apparire allo switch ad esso connesso un server DHCP, che assegna IP secondo una subnet definibile dall utente, ed imposta il default gateway al nodo 2 e un server DNS al nodo 3, che 41

42 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web non fa altro che instradare le query al DNS di default della macchina reale. Il vantaggio rispetto a TUN/TAP di slirpvde è la possibilità di instradare il traffico VDE verso la rete reale senza privilegi amministrativi; lo svantaggio è che, proprio per il fatto di essere user mode, slirpvde non è stato progettato per generare pacchetti (come ICMP) che richiedono appunto i privilegi di superutente. Se anche questo supporto ci fosse, per poterlo usare slirpvde perderebbe ogni vantaggio rispetto a TUN/TAP, dovendo anch esso essere eseguito da root. La soluzione adottata è quella di tradurre i pacchetti ICMP ricevuti dallo switch con pacchetti UDP verso il servizio echo (porta 7) del sistema reale, che se attivo li rimanda indietro immutati, e rimandarli così verso lo switch; nei casi in cui la porta 7 sia chiusa per motivi di sicurezza, un pacchetto ICMP inviato non riceve risposta. vdeq/vdeqemu. vdeq è un wrapper per collegare lo stack di rete di una VM eseguita da QEMU ad un vde_switch. La sua sintassi è: vdeq qemu_exe [opzioni...] -net vde[,vlan=n][,sock=file][,port=p] 42

43 Zoo di sistemi operativi: Idea e scenario Mentre vdeqemu esegue vdeq con qemu_exe impostato a qemu. L opzione vlan indica quale NIC emulato verrà collegato allo switch, sock il percorso del socket del vde_switch, port la porta dello switch a cui collegarsi. vdeq apre il socket di collegamento allo switch e lancia qemu_exe con le stesse opzioni, sostituendo -net vde con -net tap,vlan=n,fd=f, dove f è il file descriptor del socket. Avendo vde_switch la stessa interfaccia di TUN/TAP, la VM ottiene lo stesso comportamento di un collegamento a un interfaccia di quel tipo. La figura 2.1 mostra un esempio di utilizzo di VDE. Nel virtual once world (ossia l architettura reale e le applicazioni di virtualizzazione) due VM sono collegate a due vde_switch (connessioni 1 e 3), i quali sono collegati tra loro tramite un VDE cable (connessione 4). Lo switch che risiede sul Computer 1 effettua inoltre routing verso la rete reale, tramite TUN/TAP o slirpvde (connessione 2). Nel virtual square world (ossia l architettura emulata) le connessioni 1 e 3 diventano dei cavi 43

44 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web diritti Ethernet dai guest OS delle macchine virtuali ad altrettanti switch; gli switch sono collegati tra loro con un cavo cross (connessione 4) e uno di essi è collegato al Computer 1 tramite routing o masquerading (connessione 2). Dal punto di vista dei dati trasmessi, le connessioni 1 e 3 sono Ethernet, la 4 dipende dal canale utilizzato (TCP o UDP con netcat, TCP con SSH, UDP con vde_cryptcab, ecc.) e la 2 è Ethernet (con TUN/TAP) o Ethernet trasformato in TCP e UDP (con slirpvde). Questo esempio mostra bene la versatilità di VDE e la sua capacità di creare reti virtuali anche molto diverse da quelle reali su cui si appoggia. Per questo motivo, e per il suo supporto a QEMU, VDE verrà usato in questo progetto per far apparire le macchine virtuali eseguite su un server collegate direttamente alla rete del client Virtualizzazione di rete: Ale4NET26 Si tratta di un progetto concluso, confluito dentro View OS, che aveva lo scopo di creare un ambiente di rete completamente a livello utente. Funziona tramite una libreria dinamica (caricata con LD_PRELOAD) che intercetta e virtualizza le syscall relative alla rete Virtualizzazione di file system Viene ora presentata una veloce carrellata dei più utilizzati sistemi per la virtualizzazione di file system, un tipo di emulazione molto usato nella pratica. chroot. Questo meccanismo realizza qualcosa di simile a una virtualizzazione: mostra a un determinato albero di processi un file system diverso rispetto a quello visto dal resto del sistema, che in realtà non è altro che un sottoalbero del file system originale. L implementazione è ridotta a una singola system call: è dunque il kernel stesso a offrire questa funzionalità. chroot() richiede i permessi di amministratore della macchina (root); il kernel non fa altro che cambiare la radice del file system, solamente per il processo che esegue

45 Zoo di sistemi operativi: Idea e scenario la funzione e per i suoi figli, a quella specificata nei parametri. Spesso chroot viene usato come metodo per confinare alcuni programmi, ma i limiti non sono trascurabili: non viene virtualizzato altro che il punto di origine del file system: questo comporta per esempio il dover utilizzare altri strumenti per virtualizzare la rete e, anche relativamente allo stesso file system, si tratta di un meccanismo poco flessibile; esistono diverse questioni relative alla sicurezza da tenere presente. Non è possibile dare a un utente privilegi di root all interno di una gabbia chroot senza che questo abbia facilmente la possibilità di uscirne e accedere al resto del file system; addirittura, è sufficiente concedere a un utente la possibilità di effettuare ulteriori chiamate a chroot(), (per esempio con un eseguibile set user id oppure usando le capability di Linux) pur non essendo superutente, per permettergli di sfuggire dal sottoalbero. FUSE27. Vuole permettere l uso di driver a livello utente per montare file system, virtuali o reali. Non è una vera macchina virtuale, in quanto non discrimina tra processi virtualizzati o meno, ma applica a tutto il sistema gli effetti della propria esecuzione: un qualunque file system montato attraverso FUSE viene visto da tutti i processi allo stesso modo. FUSE è composto da tre livelli: Un modulo per il kernel, che si interfaccia con VFS, il livello di astrazione per il file system di Linux; esso crea anche un device (/dev/fuse) per permettere di interagire col modulo. Da Linux , il modulo FUSE è incluso nel kernel Linux ufficiale. Una libreria, che permette il colloquio tra il device citato sopra e i moduli dei file system, trasformando le richieste dal device in un insieme di chiamate corrispondenti alle system call relative ai file (open(), read(), write(), close(), unlink(),...);

46 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web un implementazione di file system, scritta usando la semplice interfaccia esportata dalla libreria. Questo modulo in realtà è un file eseguibile, che viene invocato dal comando mount. Una volta avviato si registra, tramite la libreria, nei confronti del kernel e resta in attesa su un file descriptor assegnato tramite /dev/fuse. Sarà poi cura del kernel rivolgersi ad esso tramite questo canale per richiedere l esecuzione del codice relativo alle varie system call. FUSE ha un interfaccia semplice, per la quale è facile scrivere moduli; per questo UMView ne ha fatto largo uso (vedi paragrafo ) Unionfs28. Questo progetto parte dalla constatazione che esistono esigenze diverse tra utenti e amministratori di un sistema: spesso un amministratore vuole avere dati, software e configurazioni in luoghi (anche geograficamente) separati, oppure mantenere su dischi o partizioni differenti dati logicamente correlati; un utente, invece, trova intuitivo vedere tutto ciò di cui ha bisogno in un unica posizione. La soluzione proposta da Unionfs è quella dell unificazione: più sorgenti (branch) di dati vengono fusi e mostrati come uno solo ai processi. Un tentativo di implementazione potrebbe lavorare direttamente su un tipo di file system che permetta queste possibilità; questo però inciderebbe sulla semantica dei file system Unix, creando problemi di compatibilità. La soluzione di Unionfs è la virtualizzazione, cioè realizzare uno strato che mantenga la semantica Unix e riesca a fondere le visioni di diversi file system, siano essi su partizioni fisiche, immagini logiche, dischi removibili o parte di essi. Unionfs fa uso di una serie di livelli che corrispondono alle varie sorgenti di dati; ad ogni livello è associata una priorità, e la visione viene data fondendo questi livelli e agendo sul file system a priorità più alta in caso di conflitti. I possibili usi di uno strumento come Unionfs sono molteplici:

47 Zoo di sistemi operativi: Idea e scenario un utente può vedere i suoi dati in un unico luogo, mentre l amministratore li conserva su supporti diversi, ad esempio per catalogazione; diventa possibile aggiungere e usare software da un immagine o da un CDROM semplicemente fondendone il file system con quello del sistema; snapshotting: è possibile fotografare il sistema, creando un archivio in sola lettura contenente un backup; nel frattempo, i dati nuovi vengono salvati in un archivio temporaneo, che contribuirà a creare il nuovo backup del sistema, e così via. sandboxing: a volte si utilizzano sistemi il cui stato viene periodicamente reimpostato alla situazione iniziale, per esempio per usi sporadici o da parte di utenti non fidati. Anche questo è realizzabile con due livelli, il primo a sola lettura, il secondo cancellato ad ogni ripulitura della sandbox. Unionfs viene implementato tramite un modulo kernel che, una volta caricato e usato, crea un nuovo layer che si presenta come un nuovo tipo di file system nei confronti del kernel e come VFS nei confronti dei gestori dei file system unificati Virtualizzazione di CPU: Apple Rosetta29 e Universal Binary30 Si tratta di due tecnologie introdotte nel 2005 da Apple Computer. Vengono discusse entrambe qui in quanto rispondono a una stessa esigenza, anche se Universal Binary non è una vera tecnologia di virtualizzazione, ma solo un sistema per produrre codice eseguibile su processori diversi. Apple ha sviluppato queste tecnologie dopo aver deciso di sostituire i processori PowerPC, che fino ad allora avevano equipaggiato le sue macchine, con processori Intel (in particolare la serie Core). Si trattava di dover supportare applicazioni per due

48 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web architetture diverse tra loro (si ricordi che x86 è little endian e CISC, PowerPC big endian e RISC) e Apple aveva sostanzialmente due strade: Consegnare due versioni delle proprie applicazioni e di MacOS, rendendo così impossibile avviare vecchie applicazioni PowerPC con i nuovi computer; Puntare tutto sull interoperabilità, consentendo l esecuzione di qualsiasi codice su entrambi i processori. La prima strada, oltre a non dare alcuna compatibilità all indietro, rischiava di vedere gli utenti PowerPC abbandonati dagli sviluppatori terzi, che avrebbero potuto scegliere di sviluppare solo applicazioni Intel preferendo non sprecare risorse per un architettura con una base di utenti sempre più ridotta; questo avrebbe potuto ridurre la già scarsa (se confrontata a quella dei PC) clientela Mac, danneggiando quindi Apple. Universal Binary e Rosetta sono il risultato della scelta di Apple di seguire la seconda strada. Universal Binary è un formato31 di file eseguibile che unisce in un unico file codici macchina di architetture diverse (è possibile scegliere tra x86, PowerPC e PowerPC a 64 bit), con un header che indica quali codici sono disponibili e il loro offset. Un sistema operativo MacOS con supporto Universal Binary, incontrando un eseguibile di questo tipo, cercherà ed eseguirà direttamente codice nativo per la propria architettura, senza alcun degrado di prestazioni. Questo sistema fu adottato da Apple anche a metà anni 90, sempre a causa di una transizione di architettura, con i Fat Binary32, che includevano codice Motorola e PowerPC. Se Universal Binary permette l esecuzione di software nuovo anche su vecchi sistemi Apple, Rosetta serve ad eseguire il vecchio software (compilato solo per PowerPC) sui sistemi Intel. Rosetta è un emulatore33 [App2006] di processore PowerPC per Intel con traduzione dinamica delle istruzioni, che funziona esattamente come QEMU in

49 Zoo di sistemi operativi: Idea e scenario user emulation. Quando un applicazione viene lanciata sotto MacOS X per Intel e il sistema si accorge che il suo codice è per PowerPC, lo esegue all interno di Rosetta, che traduce il codice PowerPC in codice Intel facendo caching delle routine tradotte, in modo che più richieste della stessa routine causino l esecuzione di una sola traduzione, velocizzando l emulazione. Le prestazioni variano a seconda delle applicazioni (quelle con maggiore riuso di codice sono le più avvantaggiate) e non tutte le applicazioni PowerPC sono eseguibili con Rosetta: non sono supportate, ad esempio, applicazioni per MacOS 9 e precedenti (che usano un formato di eseguibile diverso), applicazioni PowerPC 64 e bytecode Java che usi JNI o che sia eseguito come applet da un browser PowerPC. Per questo motivo Rosetta non può che essere una soluzione transitoria, per eseguire quelle applicazioni non ancora disponibili in versione Intel o Universal Binary Virtualizzazione generale: View OS/UMView34 A conclusione di questa carrellata delle virtualizzazioni a livello di processo, si esaminerà ora View OS, un altro progetto Virtual Square che si pone l obiettivo di dare ad ogni processo attivo su una macchina una visione diversa del sistema. View OS, ideato e sviluppato da Renzo Davoli con l assistenza di alcuni studenti del dipartimento di Scienze dell Informazione ed altri provenienti da altri corsi, vuole infatti superare la limitazione di tutti i sistemi di virtualizzazione a livello di processo, che è il dare all intero sistema la stessa visione emulata. Si vuole permettere ad un singolo processo di accedere in modo diverso a risorse come il file system o la rete rispetto a tutti gli altri, senza ricorrere ad intere emulazioni del sistema operativo (come UML) ma virtualizzando solamente le risorse desiderate. Con View OS si vuole [Gar2006, Gas2006]: Poter ridefinire system call e introdurne di nuove, mantenendo l interfaccia di quelle esistenti per garantire

50 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web compatibilità binaria (ossia poter usare le applicazioni con le nuove system call senza bisogno di ricompilarle); Modularizzare le virtualizzazioni, ossia applicare solamente quelle richieste, e comporle sia in senso orizzontale (ossia mostrando al processo una macchina virtuale ottenuta dall unione delle virtualizzazioni in uso) che in senso verticale (ossia permettendo ai moduli di appoggiarsi ai livelli di virtualizzazione forniti da altri moduli); Permettere operazioni normalmente riservate ad utenti con privilegi amministrativi a qualsiasi utente, virtualizzandole con l esecuzione di codice non privilegiato per mantenere la sicurezza. Le possibili applicazioni di View OS sono molteplici: Emulazione di operazioni privilegiate: per esempio, dare al processo l accesso a una syscall mount() per far vedere ad un utente il contenuto di un immagine ISO senza modificare i permessi di mounting in /etc/fstab, oppure creare una rete virtuale la cui configurazione sia interamente gestibile dall utente, pur non andando a modificare la rete reale sulla quale si appoggia. Sicurezza: si possono nascondere al processo porzioni di file system, reti, altri processi, in maniera più flessibile di chroot o del filtering IP (ipfwadm, ipchains, iptables), per testare programmi che modificano parti critiche del sistema o software sconosciuto e potenzialmente dannoso. Mobilità: grazie allo spazio di indirizzi reso disponibile da IPv6 è possibile assegnare indirizzi IP a singoli processi e virtualizzarli con applicazioni come VDE, per poter interromperne e riprenderne l esecuzione in modo trasparente e a caldo. 50 Prototipazione: si può estendere, con minori costi

51 Zoo di sistemi operativi: Idea e scenario computazionali, la possibilità data da UML di testare kernel senza bisogno di una macchina reale o di una virtualizzazione completa. Per esempio è possibile costruire strutture di reti di complessità arbitraria e molto leggere, staccate dall ambiente reale e quindi rispettose della sicurezza di tale ambiente. View OS può essere implementato essenzialmente in tre modi: Ridefinendo le chiamate a librerie dinamiche, in modo che i processi che le usano non passino dalle system call reali ma da quelle ridefinite, utilizzando il preloading di librerie dinamiche tramite LD_PRELOAD; soluzione poco sicura, in quanto scavalcabile sia dai processi compilati staticamente che da tutti gli altri chiamando direttamente le system call, e quindi non attuata. Realizzando una macchina virtuale parziale simile a quella di UML, utilizzando la system call ptrace() per tracciare le chiamate effettuate dai processi; pur richiedendo molti context switch ed essendo quindi meno performante del precedente, questo metodo è nettamente più sicuro nel trattare processi maligni e permette di mescolare system call ridefinite e reali, a seconda delle esigenze. Questo metodo è stato implementato dal gruppo di sviluppo View OS, con il nome di UMView. Integrando View OS nel kernel del sistema operativo host, segnatamente Linux, in modo che il kernel stesso fornisca i meccanismi per dare viste diverse a processi diversi, magari separando il codice di gestione delle varie risorse virtualizzabili, come avviene nei microkernel. Il processo di integrazione è attualmente in corso. UMView è composto da un nucleo, che esegue i processi tracciandone le system call, e dai moduli eseguiti quando il nucleo stabilisce che una certa syscall non deve essere eseguita direttamente ma emulata. La scelta fra esecuzione diretta ed emulazione dipende dalla system call e dal tipo dei suoi parametri; possono essere emulate le system call che operano su file, su socket (in base alla famiglia di 51

52 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web indirizzo) e su file system (in base al tipo del file system). I moduli attualmente implementati sono tre moduli di testing (real e sockettest per accedere al file system e ai socket in maniera diretta, unreal per replicare in una cartella fittizia il file system reale) UMFuse, un modulo per l utilizzo dei gestori di file system di Fuse, UM LWIPv6, che funge da ponte verso LWIPv6, stack TCP/IP in modalità utente derivato da lwip35, e ViewFS [Gar2006], che mostra ai processi visioni personalizzate del file system. È stato anche implementato il meccanismo di composizione orizzontale e verticale per i moduli [Gas2006] Virtualizzazione di linguaggio di programmazione La panoramica delle emulazioni verrà ora conclusa con un accenno ad alcuni esempi di virtualizzazione relativi a linguaggi di programmazione. Questo tipo di emulazione mira, normalmente, a rendere il codice portabile. Il termine portabile può essere inteso, in questo contesto, in due modi. Il primo è quello di poter eseguire un codice su più architetture, o usando un linguaggio compilato per una certa architettura virtuale (anziché usare un emulatore slegato dal linguaggio, come QEMU) o rendendo interoperabili linguaggi diversi. Nel primo caso si richiede allo sviluppatore di conoscere un certo linguaggio, nel secondo si possono sfruttare le sue conoscenze pregresse ed unirle a quelle, magari diverse, di altri sviluppatori. La seconda possibile definizione di portabilità è la capacità di creare in rete un unico ambiente di programmazione, che permetta alle singole componenti di un applicazione di essere fisicamente sparse ma di poter interagire come se risiedessero sulla stessa macchina; ad esempio, sviluppando librerie su un server e utilizzandole da un client senza che questo debba avere a disposizione il codice delle librerie

53 Zoo di sistemi operativi: Idea e scenario stesse. Verranno brevemente mostrati tre esempi che realizzano entrambe le definizioni di portabilità: Java, interessante per il proprio supporto ad applicazioni Web based, che è stato sfruttato nell ambito di questa tesi, CORBA e.net. Riguardo alla prima definizione, Java ha scelto la strada del linguaggio unico su architettura virtuale, CORBA e.net quella di interoperare linguaggi diversi Java36 Il linguaggio di programmazione creato da Sun è un vero e proprio figlio del World Wide Web. L idea di portabilità dello stesso codice compilato su più architetture, come detto nel paragrafo 2.2.1, ebbe un precursore alla fine degli anni 70 in UCSD p System. Attorno allo stesso periodo [KMM1999], Bill Joy, futuro fondatore di Sun, era interessato a sviluppare un linguaggio che fondesse le migliori caratteristiche di MESA37, il linguaggio di programmazione prodotto da Xerox per Alto (il primo computer con interfaccia grafica), e C. Il progetto andò a rilento, a causa degli impegni di Joy (in particolare la gestione di Sun stessa), ed ebbe infine una prima incarnazione col linguaggio Oak del 1991, parte del Green Project, gestito dalla sussidiaria di Sun First Person Inc. Oak parve poter trovare una prima applicazione quando nel 1993 la Time Warner aprì un asta per un sistema operativo per set top box. Sun fece la sua offerta che però venne rifiutata; First Person venne riacquisita da Sun, ma il progetto trovò nuova vitalità quando Sun intuì il successo del Web e il fatto che un linguaggio per applicazioni Web based aveva le stesse richieste (codice leggero, sicuro, affidabile ed indipendente dalla piattaforma) del sistema per set top box di Time Warner. Per questo motivo Oak fu ripreso e modificato in Java, rilasciato nel Gli obiettivi di progetto di Java [GosMcG1996] sono:

54 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web Semplicità e familiarità: Java non richiede lunghi periodi di apprendimento, e soprattutto per chi conosce già C e C++ il passaggio a Java è sufficientemente rapido. Oggetti: Java è orientato agli oggetti alla radice : a parte alcuni tipi primitivi, tutta l API è costituita da classi (ottenute per estensione da java.lang.object) e interfacce. Queste sono un concetto nuovo introdotto dal linguaggio, classi virtuali contenenti solo le signature dei metodi, che possono essere implementate in maniera multipla dalle classi (mentre l ereditarietà delle classi, in Java, è singola). La libreria standard di Java non è dunque un insieme di funzioni ma un albero di classi, e i singoli programmi sono classi. Robustezza e sicurezza: il codice è controllato a tempo di compilazione ed esecuzione; i puntatori non sono espliciti e la garbage collection è automatica; l ampia API comprende classi per implementare la sicurezza nelle applicazioni, e per assicurare consistenza nei dati in uso (ad esempio le classi per IP e porte TCP/UDP). Architecture neutrality e portabilità: come detto, è stato uno dei requisiti primari di Java, e il motivo per il quale questo progetto ne fa uso. Come è noto, Java compila il proprio codice (bytecode) per una Java Virtual Machine (JVM), che lo interpreta a tempo di esecuzione. La specifica di JVM è sufficientemente aperta da essere facilmente replicabile, per questo Sun e altri produttori hanno portato Java su un ampio numero di architetture hardware e software. Alte performance: pur essendo un codice interpretato, Java è comunque molto veloce, essendo implementato in modo che l interprete non debba verificare l ambiente di run time; inoltre il garbage collector lavora come processo a bassa priorità, ed è possibile ricompilare in codice macchina le applicazioni con alte richieste di computazione. 54

55 Zoo di sistemi operativi: Idea e scenario Uso di thread, linking dinamico: Java implementa nativamente l esecuzione concorrente, con la classe Thread e le primitive di sincronizzazione, e le classi sono caricate dinamicamente a runtime, anche da remoto. La JVM è dunque una macchina virtuale il cui unico scopo è interpretare il bytecode Java per qualsiasi architettura sul quale sia implementata. Il principale svantaggio di questo approccio è quello di non potere di ottimizzare il codice per l architettura reale senza perdere portabilità. Questo influisce sia dal punto di vista delle prestazioni (l esecuzione è comunque spesso più lenta rispetto ad eseguibili compilati da altri linguaggi) che della funzionalità (le interfacce grafiche con Java sono di solito scarne e non molto curate visivamente, ed è difficile sviluppare applicazioni se è richiesto un accesso alle risorse non supportato dall API di Java) Le soluzioni a questi problemi devono necessariamente ridurre la portabilità delle applicazioni: è possibile eseguire codice di altri linguaggi e quindi linkare librerie esterne per sopperire alle carenze prestazionali e funzionali quando necessario. Java è comunque un linguaggio molto utile, soprattutto nell ambito Web: esistono infrastrutture per applicazioni server based (come le servlets e JSP) ed il pacchetto java.applet per sviluppare applicazioni Java da far scaricare ed eseguire in browser provvisti di una JVM e di un plugin dedicato. Di questo strumento, in particolare, si serve il progetto implementato per questa tesi. Un altra interessante funzionalità di Java è Remote Method Invocation (RMI) [Jav2004], middleware per l esecuzione di applicazioni distribuite che permette di utilizzare classi non fisicamente disponibili sulla macchina del chiamante. Per rendere disponibili le proprie classi, un applicazione può registrarne i riferimenti in un registro accessibile da ogni client (rmiregistry) o passarli direttamente ai client stessi. Una volta ottenuto il riferimento all oggetto, l invocazione è fatta nella maniera più trasparente possibile, lasciando a RMI (che è 55

56 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web implementato dal pacchetto java.rmi.* e dai suoi sottopacchetti) il compito di gestire la comunicazione di rete, di scaricare il bytecode delle classi invocate e di eseguire marshaling e unmarshaling dei parametri di input e output. Questo procedimento viene implementato tramite uno stub sul client, immagine dell oggetto remoto, e uno skeleton sul server, che riceve le invocazioni dallo stub e le trasforma in chiamate di funzione al metodo vero e proprio, rimandando l output o l eventuale eccezione. Attualmente Java è disponibile nelle distribuzioni J2SE (Standard Edition) e J2EE (Enterprise Edition): quest ultima aggiunge librerie per applicazioni d impresa, come gli Enterprise Java Beans (EJB) per la gestione di ORDBMS (Object Relational DataBase Management System). La distribuzione J2SE è disponibile come Runtime Environment (JRE), contenente l interprete JVM e i plugin per i browser, o come Development Kit (JDK) che contiene anche il compilatore CORBA38 (Common Object Request Broker Architecture) È un sistema vendor independent per la creazione di applicazioni distribuite, ideato dall Object Management Group (OMG). Sua caratteristica principale è quella di gestire l interazione fra codice scritto in linguaggi di programmazione diversi, supportando (attualmente) C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python. Per attuare questa interazione, CORBA si serve [OMG2004] dell Interface Definition Language (IDL), un meta linguaggio di programmazione per definire interfacce e funzioni; esiste un mapping dell IDL per ogni linguaggio supportato, che converte la descrizione formale in codice compilabile. Una volte definite le interfacce degli oggetti, è possibile implementarle ed implementare altri oggetti che le utilizzino, senza alcuna necessità che le due implementazioni siano fatte con lo stesso linguaggio. L oggetto implementato ha un proprio identificatore univoco; il client lo invoca utilizzando uno stub, il quale dialoga con lo skeleton del server, associato all implementazione

57 Zoo di sistemi operativi: Idea e scenario dell oggetto. La comunicazione avviene tramite l Object Request Broker (ORB), che gestisce anche la comunicazione per altri modi di invocazione supportati da CORBA, come il DII (Dynamic Invocation Interface), una versione interpretata di IDL. ORB permette la comunicazione fra stub e skeleton anche attraverso la rete, in maniera del tutto paragonabile a RMI. In effetti è possibile un comparazione completa tra RMI e CORBA; l unica differenza sostanziale è che in RMI la portabilità del codice è realizzata tramite un linguaggio slegato dalle architetture reali, Java, mentre in CORBA serve un ulteriore livello, realizzato da IDL. Si può anche dire, in effetti, che Java è l IDL di RMI Microsoft.NET39 Microsoft.NET Framework è un altro middleware per l interazione tra linguaggi di programmazione diversi e per la costruzione di ambienti di programmazione distribuiti. La versione attuale (2.0) supporta 24 linguaggi di programmazione, tra cui C++, C#, COBOL, Fortran, Pascal, Java, Scheme, ML e Visual Basic..NET deriva dall esperienza di COM (Component Object Model), altro middleware Microsoft40. I linguaggi sono gestiti [Mic2006] dal Common Language Runtime (CLR), agente che fornisce alle applicazioni in esecuzione gli ambienti di runtime necessari, la gestione della memoria e dei thread, i collegamenti remoti, mantenendo type safety ed altre proprietà di sicurezza e robustezza del codice. L altro componente principale di.net è la class library, una API portabile utilizzabile in ciascuno dei linguaggi supportati per sviuppare applicazioni di ogni tipo, dalla riga di comando alla GUI e al Web. L interoperabilità del codice è garantita se questo soddisfa la Common Language Specification (CLS), una serie di feature imposte da.net sia sul codice scritto che sui compilatori; le regole di CLS

58 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web riguardano identificatori, tipi, classi, interfacce, array, enumerazioni ed altro. Per esempio, è permesso l overloading dei metodi ma non degli attributi; i puntatori sono vietati; è definito un insieme di tipi primitivi, dai quali sono esclusi, tra gli altri, i numeri senza segno (come unsigned int di C++). CLS richiede quindi sia dei compilatori dedicati, sia un codice scritto secondo certe regole; in generale, un programma corretto scritto in uno dei linguaggi supportati da CLS non necessariamente ne soddisfa le regole. In caso affermativo,.net compila41 il codice nel proprio IDL, Common Intermediate Language (CIL), che verrà a sua volta compilato in bytecode ed eseguito da CLR. Come Java e CORBA, anche.net possiede uno strumento di invocazione remota,.net Remoting. Gli oggetti remoti possono essere utilizzati per riferimento, o proxy (Marshal By Reference) o per copia locale (Marshal By Value: richiede che l oggetto sia serializzabile), e il client che li incorpora compie le invocazioni desiderate sulla copia o sul riferimento ottenuto. Non tutti le classi sono remotable ; in particolare, i tipi primitivi della class library non possono essere invocati al di fuori del proprio dominio di applicazione..net, dunque, si comporta in maniera del tutto analoga a CORBA, pur avendo un maggiore supporto di linguaggi. A vantaggio di CORBA (e di Java) va detto comunque che.net resta un sistema Windows centered, che necessita l uso di sistemi operativi Microsoft per essere utilizzato, almeno dalle applicazioni server, mentre lo standard OMG è stato progettato per essere architecture independent. 2.4 Network Computing Viene ora introdotto il concetto di Network Computing, sistema per l utilizzo remoto di computer. In un certo senso è anch essa una tecnologia di virtualizzazione, in quanto dà all utente l apparenza di utilizzare localmente un computer fisicamente distante dall utente

59 Zoo di sistemi operativi: Idea e scenario stesso. Il Network Computing è una tecnologia importante nell ambito di questa tesi, in quanto permette di utilizzare le macchine virtuali tramite Internet, togliendo all utente la necessità di installare un emulatore e il software da emulare sulla propria macchina. Il concetto di Network Computing (o Thin Client Computing) iniziò a prendere piede verso la fine degli anni 70, per indicare genericamente la possibilità di far collaborare più computer collegati ad una rete. L idea si è affinata nel tempo, raggiungendo il suo significato attuale nella seconda metà degli anni 90, quando col successo di Internet si cominciò a pensare di reintrodurre, in maniera distribuita, il time sharing [Cha2003]. Il Network Computing, proposto principalmente da Oracle (che stava sviluppando VNC, vedi 2.4.1) e Sun (impegnata con Java), voleva permettere infatti di usare applicazioni senza la necessità di doverle installare sul computer dell utente. Questi, al posto del proprio computer (o fat client), avrebbe avuto un Network Computer (NC), o thin client, senza hard disk né floppy disk, che si sarebbe collegato a server centralizzati per utilizzare qualsiasi applicazione. Salendo di livello, piccole e medie imprese avrebbero potuto affittare ed utilizzare software via rete fornito da Application Service Providers (ASP), senza dover gestire gli aggiornamenti, il testing delle nuove versioni, gli eventuali problemi di installazione. Inoltre i NC avrebbero dovuto costare molto meno dei PC, permettendo notevoli risparmi ai dipartimenti aziendali. Era anche possibile entrare in mercati IT in cui la competizione andava scemando, come quello delle applicazioni da ufficio (all epoca già monopolizzato da Microsoft), proponendo prodotti web based. Commercialmente il sistema degli ASP è stato un disastro, finendo nella bolla speculativa delle dot com gonfiatasi in quel periodo, e la cui esplosione avrebbe causato quella crisi dell economia mondiale di cui ancora oggi si sentono gli effetti. I motivi del fallimento furono molteplici. Innanzitutto, all epoca il Web non aveva la struttura per poter essere utilizzato come interfaccia applicativa, e il risultato era che 59

60 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web le prestazioni e l interattività di un applicazione Web based erano scarse. I NC non ressero il confronto commerciale con i computer tradizionali, che ne raggiunsero presto i prezzi e davano più margini di manovra ai rivenditori. Il risparmio ottenuto tramite l acquisto di NC e il non acquisto di licenze per l installazione locale di applicazioni veniva in realtà facilmente perso con i costi di affitto delle applicazioni e dell installazione delle connessioni di rete necessarie ad avere buone prestazioni dalle applicazioni. Infine, Internet è sempre stata una rete non centralizzata, e le applicazioni che meglio funzionano su di essa sono quelle realmente distribuite, ossia in cui ogni computer svolge task simili e può comunicare con tutti gli altri. Lo ha dimostrato (anche dal punto di vista legale) il successo di reti peer to peer come Gnutella rispetto a quelle centralizzate come Napster ed ED2K. Ancora, trasmettere dati potenzialmente critici di un azienda su connessioni Internet è certamente meno sicuro che mantenerli su una rete locale, ed anche aggiornare automaticamente dall esterno i software può causare effetti indesiderati, come incompatibilità dei file o disabilitazione di macro o script. Tecnologicamente, invece, il network computing è tuttora un interessante sistema per l utilizzo di applicazioni in rete. Un semplice esempio è l utilizzo location transparent di un certo computer, ossia la possibilità di lasciare aperta la propria sessione di lavoro locale e ripristinarla remotamente. Laddove non vi siano pressanti richieste sulle prestazioni delle applicazioni, è possibile testare e valutare nuovi programmi installandoli su un solo server, per deciderne in seguito l adozione (e, se si rimane nell ambito di una rete locale, la tecnologia attuale rende il degrado di prestazioni minimo). In questo modo si riducono anche i problemi di compatibilità hardware/software dell applicazione stessa, in quanto è sufficiente risolverli per il server (o, usando un emulatore, nemmeno per quest ultimo), consentendo così l utilizzo anche su reti eterogenee. Il Network Computing, dunque, ha molteplici possibilità da 60

61 Zoo di sistemi operativi: Idea e scenario sfruttare. Verranno qui discusse le caratteristiche di tre sistemi, con riguardo anche all accessibilità via Web, requisito centrale per questo lavoro di tesi VNC (Virtual Network Computing) Si tratta del sistema probabilmente più diffuso. Viene presentato [RSWH1998] come un passo ulteriore nel campo del network computing, in quando rende possibile condividere un intero desktop environment in rete; viene definito inoltre come un ultra thin client, in cui il carico computazionale del client e i dati di stato che esso mantiene sono ridotti al minimo. VNC, la cui ispirazione originale è il protocollo X, è stato sviluppato nel 1995 dall Olivetti & Oracle Research Center (ORC), portando l idea di Videotile, un dispositivo con schermo LCD, penna e connessione ATM per accesso a display remoti, in Java. I ricercatori di ORC si erano accorti infatti che così si sarebbe potuto accedere alle applicazioni tramite un web browser. Il client Java per Videotile era grande appena 6KB, e attorno ad esso fu sviluppato VNC. Il desktop da visualizzare sullo schermo del client (o VNC Viewer) viene codificato tramite il Remote Framebuffer Protocol (RFB) [Ric2005]. Si tratta di un protocollo stateless, che cioè non salva infomazioni di stato sul viewer ma sul server; questo permette di connettersi allo stesso server da viewer diversi, anche contemporaneamente, in modo tale che il nuovo viewer connesso ottenga lo stesso stato degli altri (desktop sharing), o quello dell ultimo connesso. Di norma è possibile disattivare, se necessario, il desktop sharing. RFB opera a livello di framebuffer, ossia di memorizzazione di immagini statiche dello schermo o di sue sottoparti rettangolari, il che lo rende indipendente dal sistema desktop utilizzato. Il server invia al viewer di volta in volta i rettangoli modificati, solo su richiesta del viewer stesso. Il sistema, che può sembrare banale, permette però in questo modo di applicare al rettangolo un qualsiasi meccanismo di codifica, concordato ad inizio connessione. Tutti i server e i viewer devono supportare l invio senza codifica, o Raw; altre codifiche 61

62 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web sviluppate sono RRE, CoRRE, CopyRect, Hextile, ZRLE. Inoltre, il fatto che sia il viewer a richiedere gli aggiornamenti rende il protocollo adattivo, poiché su reti congestionate al server arrivano meno richieste e quindi vengono inviati meno aggiornamenti; per esempio, il trascinamento di una finestra viene mostrato frame per frame su una connessione veloce, mentre vengono mostrati solo alcuni frame intermedi se la connessione è lenta. Riguardo all input, il viewer manda gli eventi di mouse e tastiera (o di un altro dispositivo, come la penna di Videotile) quando li rileva, indicando il tasto premuto e/o la nuova posizione del puntatore. Riguardo alla sicurezza, le versioni fino alla 3.3 del protocollo non criptano i dati trasmessi, ed è supportato semplicemente un sistema di autenticazione basato su password: il server manda un challenge, il viewer lo codifica con DES usando la password come chiave ed invia il response generato. Le versioni successive del protocollo aggiungono ulteriori schemi di sicurezza, anche per la confidenzialità, e come per la codifica server e viewer si accordano su quale sistema usare. RFB è stato progettato per essere estensibile, consentendo l introduzione di nuove codifiche dei framebuffer e schemi di sicurezza, e non dipende da alcun protocollo di trasporto in particolare (VNC usa TCP). Si vede così come il protocollo di trasmissione dati di VNC sia estremamente compatto, e riduca così al minimo sia la capacità computazionale richiesta al client che la banda di rete necessaria alla trasmissione. VNC è un sistema aperto, implementato ormai per tutte le architetture, sia come server che come viewer. Due interessanti implementazioni di VNC sono RealVNC42, azienda fondata dal team di ORC sviluppatore di VNC, e TightVNC43, che rilascia i propri prodotti sotto GPL. RealVNC rilascia liberamente i sorgenti della versione 3.3 e della versione 4 Free Edition; le versioni Personal ed Enterprise di RealVNC 4, che supportano l autenticazione RSA, Windows e NIS e la

63 Zoo di sistemi operativi: Idea e scenario codifica AES per le sessioni RFB, sono distribuite in versione binaria, e i server (solo per Windows) hanno un periodo di prova gratuito di 30 giorni. TightVNC introduce una nuova codifica dei frame RFB, detta Tight, adatta a connessioni con poca larghezza di banda. Entrambe le versioni di VNC comprendono il viewer, il server (diverso a seconda dell ambiente desktop da esportare) e tool per la gestione della password del server ed altre configurazioni; TightVNC comprende inoltre uno script per forzare un server a collegarsi ad un certo client. Il supporto al web è implementato con un applet Java che funge da viewer, e con un piccolo server HTTP che genera una pagina con l inclusione dell applet stessa. In definitiva, i punti di forza di VNC sono l indipendenza dal desktop condiviso e i bassi requisiti richiesti al client; proprio questa indipendenza e il mancato uso delle risorse possono generare minori prestazioni, rispetto ad altri protocolli, su computer potenti e dotati di una buona connessione verso il server Windows Terminal Services Viene ora descritto un sistema di network computing radicalmente diverso. Windows Terminal Services (TS) [Mic2004] è un estensione dei sistemi operativi server di Microsoft, introdotta con Windows NT 4.0 Terminal Services e mantenuta nei successori (Windows 2000, Windows Server 2003). Il protocollo usato da TS, Remote Desktop Protocol (RDP)44 è stato implementato anche su Windows XP, per i servizi Remote Desktop e Remote Assistance. Inoltre, esiste un client di accesso Web sempre distribuito da Microsoft, ma con il non trascurabile difetto di essere basato su ActiveX e non su Java, il che significa che tale client è utilizzabile solo con Internet Explorer. Come altri prodotti proprietari di Microsoft, non esiste una specifica pubblica di RDP. Si sa che è un estensione del protocollo ITU

64 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web T T.128, noto anche come T.SHARE [Rom1998]; inoltre nel 2000 è iniziato lo sviluppo di un client Linux per RDP, rdesktop45, il cui codice è rilasciato sotto GPL. Dai questi documenti si ricava che RDP, a differenza di RFB, utilizza un formato di invio dati su display a livello applicazione, che dunque tratta entità come finestre anziché frame. Non sembra invece implementata la possibilità, data da T.128, di connettere lo stesso viewer a più server e di interagire con le finestre di tutti in un unico desktop. RDP supporta l autenticazione appoggiandosi ai servizi forniti dai sistemi Windows sottostanti, e trasmette i dati su sessione TCP criptata. Terminal Services è probabilmente un sistema più avanzato di VNC dal punto di vista dell utilizzo efficiente della connessione (trattare finestre anziché frame dovrebbe generare meno overhead di trasmissione), ma interamente centrato su Windows (anche per quanto riguarda la possibilità di connessione Web), oltre che chiuso e proprietario. Lo stesso client rdesktop è stato sviluppato, per ammissione dell autore, per tentativi. Per questo tale sistema non verrà ulteriormente descritto NX Technology46 È un progetto più moderno dei due appena descritti ed ha come obiettivo alte prestazioni anche su connessioni congestionate o con poca banda disponibile. Sviluppato dall azienda italiana NoMachine, NX usa un protocollo basato su una versione compressa di X. NoMachine vende i propri prodotti server e distribuisce a sorgente chiusa i propri client (tra i quali è presente un applet Java, detta Web Companion), ma ha rilasciato anche i sorgenti delle librerie NX sotto GPL, permettendo così la nascita di un implementazione GPL del server NX, FreeNX47, mentre è in sviluppo una versione GPL del client, anche per supportare quelle architetture Linux per le quali il client

65 Zoo di sistemi operativi: Idea e scenario NoMachine non è disponibile, come PowerPC48. Inoltre il sito possiede una ricca documentazione, mantenuta da Gian Filippo Pinzari [Pin2006], quindi è possibile analizzare bene la tecnologia proposta. Scartando RFB, ritenuto poco efficiente, e RDP, migliore ma usato solo come estensione del sistema, NX si concentra sull efficienza del protocollo X aggiungendovi compressione dei dati in una varietà di modi, riducendo i round trip con agenti locali al server e adattando la banda a seconda dello stato della rete. Il server NX è dunque un wrapper per un server X esistente, ed è disponibile per sistemi POSIX (vale anche per FreeNX), mentre il client supporta, oltre ad NX, la connessione a server RFB ed RDP. Il trasferimento dei dati NX avviene su connessione SSH, sfruttando un server esistente sulla macchina del server NX. NoMachine stima di poter comprimere le sessioni NX tra 1/10 e 1/100 dei dati originali, e le sessioni RDP/RFB tra 1/2 e 1/10. NX non permette la connessione multipla alla stessa sessione. Un elemento interessante di NX è la Distributed Computing Architecture (DCA) Essa consente di gestire una rete di nodi (computer sui quali sia installato un server X, RDP o RFB) tramite uno o più server NX. Tali server gestiscono il bilanciamento di carico tra nodi sia a livello di sessione (instradando le richieste di connessione sui nodi meno utilizzati) sia a livello di applicazione (scegliendo il nodo sul quale eseguirla ed esportandone le finestre sull unico desktop del client). NX è un progetto sicuramente più interessante di Terminal Services, per la sua compatibilità con Linux, per la disponibilità di parte del codice sotto licenza GPL, per l uso di un client Web basato su Java, per il supporto alla distribuzione di carico. Le prestazioni lo rendono più allettante di VNC, ma il supporto nativo al solo server X suscita perplessità sulle possibilità di integrazione con lo zoo di sistemi operativi: bisognerà infatti stabilire se e come è possibile esportare il display di un sistema operativo dello zoo come sessione X gestibile da

66 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web NX, e quanto questo incida in termini di prestazioni, soprattutto rispetto ad una soluzione con VNC. Una possibilità è quella di incapsulare la sessione VNC di QEMU dentro NX, cosa già possibile con gli strumenti esistenti. 2.5 Esempi di sistemi di test per OS accessibili da Internet Per concludere questo capitolo dedicato allo scenario dello zoo di sistemi operativi è bene soffermarsi brevemente su alcuni sistemi già presenti su Internet che permettono un accesso in rete a vari OS, focalizzandosi sui loro vantaggi e svantaggi rispetto alla proposta discussa in questa tesi. Ai tre sistemi qui presentati va aggiunto anche il test drive di NoMachine (vedi 2.4.3), che permette di avere un account temporaneo sui server NX di NoMachine (configurati con KDE e GNOME su Suse o Fedora) e collegarsi ad essi con il client NX. Si tratta di una proposta buona dal punto di vista delle prestazioni (per la mancanza di emulatore e per l efficienza del protocollo NX) ma limitata, rispetto allo zoo, per lo scarso software disponibile e per l impossibilità di accesso via browser Web HP Test Drive49 Si tratta di un sistema offerto da Hewlett Packard principalmente ai programmatori che vogliono testare il loro codice su diversi sistemi POSIX e architetture diverse. Ottenere un account (che viene cancellato dopo 6 mesi di inattività) è abbastanza semplice, e viene fornito l accesso (tramite telnet) a una pletora di server HP diversi (con CPU Alpha, x86, x86_64, IA64) con sistemi operativi HP (Tru64, OpenVMS e HP UX), Linux e BSD. È disponibile anche il test di una soluzione di clustering (OpenVMS Galaxy Cluster) o di un database (Oracle RDB)

67 Zoo di sistemi operativi: Idea e scenario L accesso dall esterno ai server è consentito unicamente tramite FTP e telnet, mentre dall interno è possibile effettuare connessioni solo verso altri server Test Drive. I vantaggi di questo supporto rispetto alla proposta di zoo sono una maggiore potenza di calcolo disponibile e la possibilità di comunicazione in rete tra macchine del sistema. Gli svantaggi sono la mancanza di un accesso via web e i limiti di telnet che non permettono l uso di GUI, oltre all impossibilità di effettuare connessioni verso l esterno, politica decisa in quanto tali connessioni sarebbero provenienti dalla rete HP e quindi ogni azione non legale coinvolgerebbe HP stessa. Il supporto di rete dello zoo (vedi 3.3.6) sarà studiato specificamente per eliminare questa eventualità Linuxzoo50 Si tratta si un progetto dagli scopi molto simili a quelli del sistema proposto in questa tesi. Sviluppato dal Dr. Gordon Russell alla Napier University di Edinburgo, è infatti orientato alla didattica, fornendo non solo il supporto di sperimentazione ma dei tutorial utili ad imparare l uso del sistema emulato. Linuxzoo, inoltre, fa parte di un gruppo di siti che permettono la sperimentazione dal vivo di linguaggi di programmazione (C++, C#, Java, Perl), XML ed SQL. Linuxzoo è composto da 5 server con User mode Linux, gestiti da un server principale. L account fornito ha la durata di 7 giorni, e quando il sito è stato analizzato (17 giugno 2006) era disponibile Fedora Core 2 come sistema da provare. L accesso alle macchine avviene tramite coda: dopo l autenticazione l utente deve entrare in una coda per poter usare le UML, aspettando che chi è prima di lui liberi le macchine. Vi è un tempo massimo di connessione se la coda non è vuota. Una volta ottenuto l uso della UML, è possibile avviarla e spegnerla, connettendosi ad essa con SSH o telnet (anche tramite un applet Java) ed account root. Una volta avviata la UML, è possibile avviare all interno di essa il server Web Apache in essa incluso

68 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web (/etc/init.d/httpd start) e accedervi tramite l URL fornito da Linuxzoo. Sulle UML è installato anche X, accessibile tramite il port forwarding X di SSH. La sicurezza è un fattore tenuto in grande considerazione: l accesso ad Internet dalle UML è consentito ma completamente registrato (con ovvi limiti in caso di connessioni con NAT), come l accesso alle UML. Dalle UML non è possibile fare SSH verso l esterno (probabilmente per evitare che vengano tracciate password), né connessioni SMTP. Il login ad una UML è possibile esclusivamente all IP che ha eseguito il login sul sito di Linuxzoo. La sicurezza è una caratteristica positiva in un sistema di test di questo tipo, ma va notato che, come per HP Test Drive, molte delle necessità di sicurezza di questo sistema dipendono dal fatto che il traffico di rete delle UML viene direttamente instradato su Internet. L accesso come superutente permette comunque una maggiore libertà di azione rispetto a Test Drive. La limitazione nei sistemi utilizzabili è imposta dall uso di UML, che d altro canto garantisce migliori prestazioni. L applet Java per la connessione telnet, inoltre, funziona male con le applicazioni basate su librerie ncurses, ed è ovviamente più limitata rispetto ad un accesso con VNC Workspot51 È necessario segnalare, innanzitutto, che nel momento in cui questo sito è stato analizzato (17 giugno 2006) non è stato possibile utilizzare il sistema messo a disposizione, in quanto non era permesso né effettuare una sottoscrizione né lanciare una sessione di test. L analisi di questo progetto si baserà quindi sulle informazioni reperibili sul sito stesso. Workspot, un progetto no profit, fornisce (tramite sottoscrizione, i cui proventi dovrebbero essere destinati allo sviluppo di Workspot stesso) accesso a server Redhat e Mandrake con X, tramite sessione

69 Zoo di sistemi operativi: Idea e scenario VNC; la sessione è criptata con AES ed è possibile condividere il desktop. L utente ha accesso root sul proprio server ed ha ampie possibilità di connessione dall esterno (le porte FTP, SSH, DNS e POP3 sono utilizzabili), e può trasferire file sulla macchina remota usando WebDAV. Le versioni modificate dei client VNC che supportano AES sono disponibili dal sito, ed è presente una sessione di test che utilizza un applet Java con lo stesso supporto. Il progetto sembra abbandonato a sé stesso, in quanto oltre a non permettere alcun tipo di prova presenta documenti che fanno riferimento al Questo dispiace perché l uso di una sessione VNC criptata e l ampia libertà d uso concessa all utente sono caratteristiche interessanti anche per il progetto discusso in questa tesi. Nello sviluppo futuro, la collaborazione di Workspot e di questo progetto è un ipotesi da prendere in seria considerazione. 69

70

71 3 FREE LIVE OS ZOO: A VIRTUAL MACHINE SUPPORT WITH WEB ACCESS What is the Matrix? Control. The Matrix is a computer generated dream world built to keep us under control in order to change a human being into this. [holds up a Duracell battery] MORPHEUS, THE MATRIX This chapter deals with the actual implementation of the virtual machine support with Web access, called Free Live OS Zoo as it is the live extension of the original Free OS Zoo52, the repository of OS images for use with QEMU, already discussed in section 2.1. Free Live OS Zoo (hence called FLOZ) uses those images and makes them immediately testable by the user, without need for him to install QEMU and download the images. Section 3.1 is a user manual, intended for those who wish to launch and test a OS provided by FLOZ. Section 3.2 is a provider manual, intended for those who want to provide access to OSes to others. Section 3.3 describes FLOZ internals, such as PHP code, applet deployment, networking implementation, possible modifications. 3.1 User Manual This is a short tutorial for users of FLOZ, the Free Live OS Zoo Introduction Free Live OS Zoo (FLOZ) is a Web based OS emulation project,

72 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web aimed at giving everyone the opportunity to test any FLOSS53 Operating System simply using a Web Browser. FLOZ is designed to be easy to use for end users and easily customizable for content providers which want their users to test, experiment and learn many OSes without requiring them complex configuration. FLOZ lets you use Linux under Windows, or FreeBSD under MacOS, or Minix under Linux, simply starting your favorite Web browser. It is completely written using FLOSS and is released under GPL Requirements FLOZ is designed to have minimum system requirements for its users: A computer with an Internet connection; DSL or faster connection is recommended. Suggested screen resolution: 1024x768 or higher. A web browser. Currently FLOZ is tested with Gecko browsers (Mozilla 1.0 or later, Mozilla Firebird, Firefox, SeaMonkey, Camino, Epiphany, Galeon, Netscape 7 or later), Internet Explorer 6 or later, Opera, Konqueror. It should work on Safari, too. A Java Virtual Machine (JRE or JDK) and its corresponding browser plugin. Windows Me/XP and Mac OS X usually come with their JVM and plugin; alternatively, you could check Sun Web site54 for a version suitable for Windows, Linux (x86, x86_64) or Solaris (SPARC, SPARC64, x86, x86_64), or the Apple Web site55 for a version suitable for Mac OS56. Linux JVMs for other architectures are provided by Blackdown57. JVM required Free/Libre/Open Source Software Due to limitations in Rosetta (see section ), you can t run Java applets in a PowerPC browser for MacOS X on a Intel based Mac, even if the JVM is Universal Binary. Use a Universal Binary browser (Universal versions of Safari and Camino are available)

73 Free Live OS Zoo: A Virtual Machine Support with Web access version is 1.3 or later for non Sun JVMs, because older versions may not have browser plugin support. Future FLOZ versions could require JVM 1.4 or later. Current networking support requires a POSIX OS; future versions should provide networking also for other systems Usage without networking Once connected to the site (a trial version, without networking support, is running at the Department of Computer Science, University of Bologna58) a list of available OS images is shown. Select the OS you want to test and the actual keyboard mapping from the menu below. Note that you have to choose the keyboard mapping you are currently using, not the one you want in the emulated OS. If you want to use there a keyboard mapping different from the one you are currently running, you could do that after starting the OS itself. Once selected the desired image and keyboard mapping, click on Load image to launch it. The browser will redirect to another page, showing the OS inside a Java applet. You may need to click inside the OS display to send key typings to the OS. Unless otherwise noted, all the images of the version running at CS Department will start in a applet with the size of 725x485; the keyboard mapping of the OS is set to English (US) and there is a superuser with login root and password piripicchio. The images will have no network interface available. When you re done using the OS, you could either exit it the Shutdown button above the applet, or simply close the browser window/tab (FLOZ will kill inactive images after 4 minutes). Note that the image is run as a snapshot, i.e. a temporary copy of the real image file, so any modification made in the OS will be lost when it is shut down. 58 The trial version URL can be found at 73

74 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web Usage with networking Be fair when using networking support. Even if the OS image is connected to the Internet with your IP, and the modifications made are lost at shutdown, do not use it to do anything that could break laws, especially copyright laws, e.g. downloading and installing software for which you don t have a license of use on the images. Also, keep in mind this is a Free Live OS Zoo; do not install proprietary software on the images, even if you have a valid license for them. In the current version, if the provider has activated networking, after selecting the image and keyboard mapping and clicking Load image, the browser will show the instructions needed to activate client side networking. Basically, you should download and compile VDE 259 on your system, then launch a vde_switch to create a virtual Ethernet switch. Then, you have to launch slirpvde to connect the switch to your local network route. Finally, you ll use dpipe to connect the local virtual switch to that on the server. Now you could click the link indicated by the Web page to launch the image exactly as described in Section The difference is that now the OSes have a NIC60 whose traffic will be sent through the switch to the local network of the client, i.e. all the network traffic generated by the OS will appear as generated by the computer who connected to FLOZ. Apart from that, the behavior of the OS will be equal to that without networking, so check Section for more information Known issues For performance reasons, VNC data is not encrypted. So anyone can intercept the communication and discover your console input and screen output. Think carefully before entering passwords or other Network Interface Card 74

75 Free Live OS Zoo: A Virtual Machine Support with Web access sensitive data. FLOZ web page allows only you to view and shutdown your image, but anyone can connect to the VNC port of the server. Also, anyone who could login with SSH as www-data on the server could view your network packets. This will be solved in future releases. Due to limitations in the QEMU VNC support, some keys might not work properly even if you chose the correct keyboard mapping in the site and in the OS (e.g. the accented letters of Italian keyboards). Due to limitations of Slirp, an image run with networking won t have ICMP traffic working, i.e. no pings available. TCP and UDP will work properly, though. Some images have mouse support. In some of them (e.g. Plan961) the emulated pointer (i.e. the pointer seen by the OS) should correctly follow the real pointer (i.e. the pointer of the client system) when you put it inside the OS display; in other cases it can seem accelerated. Try to reduce mouse acceleration to the minimum value in the emulated OS. If the OS changes its resolution during emulation, the displaying may become unreadable. Reload the page to correct this. 3.2 Provider Manual This is a guide to help installing and configuring FLOZ, to make it available to end users Introduction For an introduction to FLOZ in general, see Section From the providers point of view, FLOZ is a distribution of programs, OS images and PHP code that build up a OS testing environment, accessible via the Web. The Web site, made with PHP, launches the OS images with QEMU and uploads a Java applet to the browser to make it receive the

76 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web OS image output and send input to it Requirements These are the hardware & software needs of FLOZ: A x86, x86_64 or PowerPC based computer connected to the Internet. Recommended connection: broadband (T1 or better) Recommended processor: x86_64 multiple processors or multi core processor (AMD Athlon 64 X2, FX 60, Opteron or better; Intel Pentium XE, Core Duo, Pentium D, Xeon or better) and/or HyperThreading processor (Intel only). Check QEMU Host CPU support list62 for newly added Host CPUs. The more RAM you have, the more QEMU instances you can start. 1GB or more is recommended. TCP/IP networking: VNC connection requires ports to be open, but you could limit the maximum number. Reserve also a port for the Web server. An operating system with a C compiler and standard library, and a Bourne compatible shell. Linux is OK, but Mac OS X should be good, too. Apache web server, with mod_rewrite and PHP 5 support loaded. PHP 5 or later, with the extensions XSL, CLI and Tidy. XSL and CLI are usually pre packaged with distributions, while Tidy may need to be installed via PEAR. See the PHP documentation for details on extensions and PEAR. A cron daemon, to perform periodical killing of images. QEMU ver or later, and (optionally) KQEMU ver pre7 or later. The configure program will remember you not

77 Free Live OS Zoo: A Virtual Machine Support with Web access to use gcc 4.x to compile QEMU (use configure --cc --host-cc to do so). The qemu executable should be in the system path. KQEMU, instead, MUST be compiled with the same gcc version as the running kernel. After loading kqemu module, you should create the /dev/kqemu device with this command (as root) # mknod -m 666 /dev/kqemu c (For networking support only) VDE or later. If you download VDE 2.0.2, you must not compile it with gcc 4.x; if you use the CVS version, you could compile it with gcc 4.x, and you ll need the latest version of automake (usually 1.9). The vde_switch executable should be in the system path. (For networking support only) A SSH daemon, to make the clients create a double pipe (using VDE dpipe command) between their local vde_switch and the server vde_switch. Support for other secure channels will be added in future versions Installation The public files First of all, it is recommended to choose a user account for doing configuration, and create a group including that user and www-data (or the user with Web client privileges). Put the PHP and XML files in a directory accessible by the Web Server (e.g. a subdirectory of the folder specified by the Apache DocumentRoot directive). The only files that MUST not have this accessibility are killoldimages.php and reset.php. Then download the OS images (you could get them from Free OS Zoo) and put them in a directory with read access for www-data. Let s have a look of all the files in the distribution: 77

78 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web File name Perms63 Description common.css r-- Common CSS style sheet. common.php r-- Common definitions and functions. freevnc.xml rw- List of unused VNC displays. 63 These are the minimum permissions that www-data must have on this file, shown in the standard Unix way (read, write, execute) 78

79 Free Live OS Zoo: A Virtual Machine Support with Web access File name Perms Description index.php r-- Homepage, with image and keyboard selection. keepalive.php r-- Pings active images while used. --- Script for periodical killing of unused images. oszoo.php r-- Class ZooImageList to manage available images. oszoo.xml rw- List of available images. qemu.opts rw- Contains options needed to launch QEMU. qemureturn rw- Stores output launches/killings. reset.php --- Resets normal state of displays and removes VDE control files. startqemu r-x Launches QEMU with the options specified in qemu.opts. usedvnc.xml rw- List of used VNC displays. vdereturn rw- Stores output launches/killings. vnclist.php r-- Class VNCInstanceList to manage available displays. vnclist.xsl r-- XSL Transformation to show used displays, for debugging. webps.php Shows human readable infos about FLOZ active processes and allocated displays. zoomanage.php r-- Interface to rebuild image list, update or remove images. display/.htaccess r-- Permits the translation of /display/# URLs to /display/?display=# URLs. killoldimages.php* 64 of of QEMU VDE 64 Scripts with * MUST NOT be in a Web accessible directory, and should be launched with www-data privileges 65 This script should be run as normal user from command line and requires read access to FLOZ code 79

80 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web File name Perms Description display/vncviewer.jar r-- Archive of the TightVNC Java applet. display/index.php r-- Page that displays a running QEMU image The management scripts killoldimages.php is intended to be placed in a crontab, to be run every minute or every 2 minutes. You have two choices: 1) If you put it in a user s crontab, be sure that this user has permission to perform kill and rm commands. Launch crontab -e and insert a line like this: 0-59/2 * * * * /usr/bin/php /home/user/killoldimages.php > /dev/null 2>&1 (replace the parts in italic with the real paths) 2) If you have super user access, you could put the cron job in the system wide crontab; edit /etc/crontab and insert a line like this: 0-59/2 * * * * www-data /usr/bin/php /home/user/killoldimages.php > /dev/null 2>&1 reset.php should be used if you have killed all running QEMU images manually; it resets freevnc.xml and usedvnc.xml to a no display allocated setting. Normally, you won t need to use it. webps.php is a useful front end to usedvnc.xml, showing active QEMU and VDE processes and informations about allocated displays Networking Currently, you should provide SSH access to your users to make them use network with their images. Specifically, users should login via SSH as www-data user. To do so you could either provide a www-data password to your users, or get the public SSH keys of your users, create a home directory for www-data (not a subdirectory of Apache DocumentRoot) and create under it a file named authorized_keys in the subdirectory.ssh/, in which you ll put your users public SSH keys (the file must have permissions 0600). This way, your users should connect 80

81 Free Live OS Zoo: A Virtual Machine Support with Web access without typing passwords Customization Configuration constants Once the scripts are copied to the Web folder and killoldimages.php is set up in a crontab, you ll have to configure FLOZ for your system. Edit common.php; at the top of the file you ll see some PHP constants definitions, in the form: define("name", value); You should set these constants. It s safe to leave the other ones unmodified. NAME Value type66 Description DEBUG_ON Boolean Whether to send verbose debug messages. PROJECT_NAME String The Web site name. CMDLINE_USER String The user who will run killoldimages.php HOST_SITE String The server name for SSH (networking only) HOST_WEB String Set it to make the site URL. VNC_FIRST_DISPLAY VNC_LAST_DISPLAY Integer First and last VNC display numbers available for FLOZ. Set FIRST to 1 to use a local X server. Do not set values smaller than 0 and larger than 99, respectively. Run reset.php after every change. SUDO String If you run killoldimages.php as normal user, set this prefix to something like "sudo -u www-data "; otherwise set it to "". 66 Boolean is true or false, String is everything inside "", Integer is a number. 81

82 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web NAME Value type Description DISPLAY_TIMEOUT Integer Maximum lifetime for a OS, in seconds. UTILIZATION_TIMEOUT Integer When a user leaves OS display page, FLOZ kills this image after this time in seconds. QEMU_USES_NETWORK Boolean Activate networking support. DATA_H String Full local path of the site directory. IMAGE_DIR String Full path of QEMU images. ZOO_KBMAP_DIR String The path in which QEMU installed its set of keyboard mappings; normally it is /usr/local/share/qemu/keymaps/ USE_KQEMU Boolean Whether to use QEMU Accelerator module. For more information about data types in PHP, see PHP documentation. You should be done now! Start your testing Managing images If you point your browser to you can manage your list of available QEMU images: To add or remove images, put or delete them from the IMAGE_DIR folder and click Rebuild image list ; To update settings for an image (title and applet size) select it and click Update image. Enter new values and click Update image again. To make a image temporary unavailable for use, select it and click Disable image ; to re enable it, click Enable image. 3.3 FLOZ Internals FLOZ is, in fact, a Web front end to QEMU. Its purpose is to get a 82

83 Free Live OS Zoo: A Virtual Machine Support with Web access request from Web user agents and launch a QEMU process which satisfies that request. It is made to be highly customizable by those who want to provide a live selection of FLOSS Operating Systems, and relatively simple for end users. Another goal is to reduce hardware and software requirements for end users to the minimum, to give everyone the opportunity of discovering a (mostly unknown) world of Operating Systems. For this reason, an effort has also been made to produce a browser compatible and standards compliant Web interface. This section will examine in detail all the technical aspects of FLOZ, giving explanations for the design choices that were made, according to the design goals expressed above The images FLOZ project has strong ties with the Free OS Zoo project; both projects were inspired by Renzo Davoli in the course of Operating Systems Development, in the spring term of the academic year 2003/2004. Free OS Zoo is basically a collection of OS images for use with QEMU; users can download them, together with a QEMU distribution suitable for their machine, and launch them. When this project started, it was natural to use the images provided by Free OS Zoo to build the system and do the first tests. In the future the two project will be more integrated, with common images and a common site, to give the opportunities of downloading a OS image and testing it from the site in the same place. Some demands raised when building the system around Free OS Zoo images. First of all, the need to give a common interface for users, in order to make a common set of instructions to use OS images. A common interface means: Common keyboard mapping. Since it s difficult to change the keyboard mapping of a OS image from outside (because every OS has a different place in which it stores keyboard information) it s a good choice to provide the user with always 83

84 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web the same keyboard mapping when the OS starts. The English (US) keyboard mapping was chosen, because it s the layout of the machines in the Laboratories of the CS Department of Bologna University, where the first tests were made, and because it s probably the most widespread keyboard layout. Obviously, it s necessary to provide each OS image with a wide set of keyboard mappings, to suit the widest range of users. Common user account. Since it is a test system, and (in the current version) no modification is written in the OS image, there s no particular need of security and privacy in the user accounts set up in the OS images. Moreover, the user needs access to the OS to test it, and most of the Free OS Zoo images require accounts with a password. So the best solution is to have the same login data for every image. Some of the images present in Free OS Zoo have a root account with password piripicchio, and that choice was taken for FLOZ images. piripicchio is a alphanumeric password (so it can be typed by most keyboard layouts without problems) and it is sufficiently long to be accepted by password checkers. Another demand raised during FLOZ testing was about the resolution of the OS display. Like keyboard mapping, changing OS resolution from outside is not easy, so a policy of determining the host screen resolution and thus adapting the OS to it is not applicable. Moreover, it should be thought that the applet won t take all the host screen, due to Web page title, text and borders, browser borders, other elements on the screen (window title, toolbars, scroll bars...); so the OS resolution shouldn t be too high. It was decided to keep a maximum resolution of 800x600 pixels, for operating systems using GUI or a frame buffer interface, while text mode OS (80x25 chars) usually need 720x480 pixels. These settings should make OS displays fit well in a 1024x768 screen, which is a typical resolution in modern desktop and laptop PCs. In the future, these settings may be put also in the images 84

85 Free Live OS Zoo: A Virtual Machine Support with Web access available on Free OS Zoo, to make single copies of the images themselves, suitable for both live testing and downloading FLOZ back end: QEMU VNC server The core of FLOZ is QEMU and its VNC interface. QEMU was discussed in Section , and VNC in This section will discuss the VNC support for QEMU. VNC interface is a relatively new feature of QEMU; it has been discussed since 2004, with many coders working on it, but the first stable version with VNC support was 0.8.1, released on May 3, 2006, which uses the patch made by Anthony Liguori, applied to the QEMU CVS tree on April 19. The first patch was made by Matthew Mastracci in April The current VNC interface works using the option -vnc in QEMU command line. Its syntax is qemu [OPTIONS...] -vnc DISPLAY Where DISPLAY is a number between 0 and 99. QEMU is then launched as a VNC server listening to TCP port ( DISPLAY). Now it s possible to connect to QEMU using a VNC compatible client, like those from RealVNC or TightVNC. QEMU VNC server needs no authentication, supports Raw and Hextile encodings for frame buffers and disables desktop sharing, thus allowing only one client at time to connect. Two issues were noted in using QEMU via VNC: 1. The keys have very strange behavior, using unknown mapping. This is solved using the -k option in the QEMU command line. During compiling, QEMU creates its own key mappings from the key maps currently installed in the system, and normally places it in /usr/local/share/qemu/keymaps. Using the -k option with one of the names of these key maps makes it work correctly with VNC (note that -k isn t usually needed when QEMU is used with the standard SDL output, i.e. without the -vnc option). Actually, not all the keys of a layout are mapped in 85

86 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web QEMU key maps, so some keys are ignored (e.g. accented letters in Italian keyboards), but the overall behavior is much better using the -k option, rather than not using it. 2. If the emulated system has mouse pointer acceleration activated, the emulated pointer is accelerated compared to the real pointer. This is solved turning off acceleration in the emulated OS. Actually, this is the meaning of mouse acceleration, to make the pointer move faster than the real mouse movement; in this case the real mouse movement is in fact another pointer FLOZ front end: PHP and Java applet Figure 3.1: FLOZ displaying system If we didn t want Web access for emulated OSes, the work would be finished now; it would be just a matter of installing a VNC viewer and connecting to QEMU using it. To provide Web access, QEMU needs a VNC viewer embedded in a Web page. The Web VNC viewer is implemented through a Java applet, while the Web pages are made with PHP. The complete front end/back end scheme is shown in Figure

87 Free Live OS Zoo: A Virtual Machine Support with Web access PHP and XML Let s start with PHP67 (PHP: Hypertext Preprocessor). It is a general purpose scripting language that is especially suitable for Web applications, and can be embedded into HTML. Its syntax is borrowed mainly from C, Java and Perl, with a notable overload of functions. PHP has a huge function library; in this section we ll deal with the libraries required by FLOZ, which regard XML, XSL, semaphores and Tidy. PHP comes also with a API for implementing classes and interfaces like in Java (with single inheritance and interface definition), called SPL (Standard PHP Library), and a Command Line Interface (CLI) The Extensible Markup Language (XML) is the most important standard [BPS+2004] proposed by the World Wide Web Consortium (W3C). It is a non proprietary declarative meta markup language, i.e. it allows to define markup, its formal syntax and also its semantics. It s designed to be human and machine understandable, with documents made of plain text. Many current applications use XML for data storage and interchange; there are XML office documents (DocBook, OpenDocument), XML multimedia files (SMIL), XML graphics (SVG), as well as XML Web documents (XHTML). XML comes with a family of complementary languages that implement validation (XSD), multiple inclusions (XML Namespaces), indexing (XPath and XPointer), linking (XBase and XLink) transforming and style sheeting (XSL and XSLT) ZooImageList class In FLOZ, XML is used for managing the list of available OS images and the list of free and used displays. The first list is implemented using the ZooImageList class, whose definition is in the file oszoo.php, with the XML content stored in oszoo.xml. Let s have a look at ZooImageList members: class ZooImageList implements Iterator, Countable Member Description $dom; Variables used by Iterator methods

88 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web Member Description $listxml; $sem; System V mutual exclusion semaphore to gain exclusive access to oszoo.xml. construct(); Constructor, initializes the semaphore. reinit(); Puts in the list images newly put in IMAGE_DIR, and removes images no more present in that directory. int count(); Countable list. method, returns the size of image rewind(); next(); boolean valid(); DomNode current(); int key(); Iterator string currentfile(); int currentx(); int currenty(); int currentdesc(); Show data of the current iteration element, like filename, resolution and description. getlock(); releaselock(); P() and V() on $sem, respectively. updateimage(int number, string newdesc, int newx, int newy); Updates data for the (number+1) th image. lockimage(int number); Disables the (number+1) th image in the list. unlockimage(int number); Enables the (number+1) th image in the list. boolean islocked(int number); Checks if the (number+1) th image is enabled or not. methods. rewind() starts a new iteration, next() goes to the following image, valid() checks that the iteration is not over, current() returns current element, key() returns the position of current image in the list. zoomanage.php is the Web front end for the methods of this class; reset.php uses reinit(). oszoo.xml has a document element called <oszoo>, whose content is zero or more <image> elements. Each <image> has the attributes file, X and Y, and its #PCDATA content is the image description. 88

89 Free Live OS Zoo: A Virtual Machine Support with Web access VNCInstanceList class The list of displays is in fact implemented using two XML documents, freevnc.xml for unused displays and usedvnc.xml for used ones. They both have a document element called <displaylist>, whose content is zero or more <display> elements. The following table shows the attributes of <display> in usedvnc.xml (only number is used also in freevnc.xml): Attribute Description number Display number. timestarted Time at which the display was allocated, in seconds from Epoch. lastused Time of the last ping sent by the Web page, in seconds from Epoch. description OS image description, taken from oszoo.xml. keymap Value for the -k QEMU parameter. vdeqemu Whether the OS image is using networking support. filename OS image file name, taken from oszoo.xml. pid PID of the QEMU process, 0 if it hasn t been started yet. vdepid If vdeqemu is "true", PID of the vde_switch process used. callerip The IP of the client. The class that manages this list is VNCInstanceList, implemented in vnclist.php. Let s see it in detail: class VNCInstanceList implements Countable Member Description $dom, $listxml, $xpath; Temporary variables used to perform operations on the list. $sem; System V mutual exclusion semaphore to gain exclusive access to usedvnc.xml and freevnc.xml. construct(); Constructor, initializes the semaphore. reinit(); Fills freevnc.xml with free displays and empties usedvnc.xml. int count(); Countable method, returns size of used image 89

90 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web Member Description list. getlock(); releaselock(); P() and V() on $sem, respectively. int allocatevnc(string imagedesc, boolean vdeqemu, string filename, string kb, string ip); Allocates a free VNC display with associated image file name and description, keyboard mapping, caller IP, and returns its number. vdeqemu specifies if the display will use networking support. freevnc(int display); Free the specified used VNC display. boolean isused(int display); Checks if display is allocated for use. string getfile(int display); string getdesc(int display); string getkeymap(int display); int getlastping(int display); int gettime(int display); int getip(int display); Return the corresponding attributes of display. getfile() returns the image file name, getdesc() its description, getkeymap() the keyboard mapping, getlastping() the lastused attribute, gettime() the timestarted attribute, getip() the callerip attribute. boolean isvde(int display); Checks if display is using vdeqemu. setqemupid(int display, int pid); Sets qemu PID. int getqemupid(int display); Gets qemu PID. setvdepid(int display, int pid); Sets vde_switch PID if display is using it. int getvdepid(int display); Gets vde_switch PID if display is using it. ping(int display); Sets the lastused attribute of display to the current time. showlist(); Shows the list of used displays in a Web page, for debugging purposes. It uses the XSL extension of PHP 5. array usedlistdump(); Returns an array with all attributes of used <display> elements. Most of these functions throw exceptions if a error occurs (e.g. a freevnc() 90 called for an unused display), using the Exception class

91 Free Live OS Zoo: A Virtual Machine Support with Web access defined in PHP. See the source for more info. It s easy to understand that VNCInstanceList is the key class in FLOZ. The two PHP files that create web pages, index.php and display/index.php, both make huge use of this class, and also killoldimages.php and reset.php use it common.php: verifypid() functions Other interesting control functions are in common.php. This file contains, as we ve seen in Section 3.2, a set of constants, some of which need to be set by a provider who wants its users to test OSes with FLOZ. But common.php also contains a huge set of functions, the majority of which is used for Web page rendering and will be discussed in the next section. Four of them, instead, are used for PID verification when a image is shut down manually or via killoldimages.php. These functions are verifypid() and its wrappers, verifyqemupid(), verifyvdeqemupid() and verifyvdepid(). int doption) verifypid(string executes a ps x regexp, int command (or ps pid, int display, string ax, if it is launched from killoldimages.php), checks its output for a command line starting with regexp (using regular expression matching) and ending with the concatenation of doption and display (this command line is a qemu, vdeqemu or vde_switch launched by FLOZ, depending on regexp); if it finds it, returns its PID. Future versions of this function will try to match /proc/pid/cmdline with the regular expression described above, and only in case of failure will use ps. For this reason the input parameter pid is specified. With both versions of this function, in a normal situation, the pid parameter and the return value of verifypid() should be equal. In the case of a PID reassignment, verifypid() should return the right PID. The wrappers provide regexps coherent with their names. 91

92 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web common.php: web standards and browser compatibility The other functions in common.php, as said, serve web page rendering only. Let s have a quick overview: Function Description startpage() <?xml?>, <!DOCTYPE > and <html> headtitle() <title> headstart() headend() <head> and </head> bodystart() bodyend() <body> (with optional attributes) and </body> endpage() </html> and Tidy output formatting, using PHP Tidy extension. link_rel(), <link />s and <meta />s for <head> link_rev(), link_common(), meta(), meta_http(), meta_common() functions from TB() to Browser recognition, to adapt generated code to it. badbrowseridx() Makes a ^ top link, for long pages. top() br(), strbr(), hr(), <br /> and <hr />. cmempty() strhr(), cmempty(), end of empty elements. strcmempty() controls the / at the image() <img /> changebrowser() Prints a disclaimer if a browser with bad CSS support is detected. The common purpose of all these functions is to output a web page with the most advanced HTML specification the browser can support. If a good browser is detected ( good basically means a good CSS2 support) the output should be XHTML 1.1 with CSS, otherwise it is XHTML 1.0 Transitional or HTML 4.01 Transitional without CSS. The PHP Tidy extension (called by the endpage() function) also polishes output, verifying that tags generated are compliant with the specification declared. There is an issue with the use of XHTML 1.1 and the Java applet. The latter is rendered with the <applet> tag, which is recognized by most browsers. Alas, <applet> is a HTML 4.01 deprecated tag, and it s 92

93 Free Live OS Zoo: A Virtual Machine Support with Web access not valid XHTML 1.1, so display.php outputs XHTML 1.0 Transitional. With Internet Explorer, an alternative is to use the <object> tag instead of <applet>, but <object> is not recognized by Mozilla compatible browsers. So it s impossible to have a XHTML 1.1 compliant output for every browser that supports it The Java applet The Java applet of TightVNC and its connection protocol are dealt with in section Here we ll discuss shortly what modifications were made to the applet and what are planned for future versions. Current modifications are little adjustments to adapt a general VNC viewer to its particular target, i.e. QEMU: Like any VNC viewer, the original applet asks for authentication when connected to a VNC server. Current QEMU VNC support doesn t need authentication, so this was disabled in the applet code. The applet shows by default a button bar at the top of the window. These button provide functions not necessary for FLOZ, so the bar was disabled. It can be re enabled by adding the following line to display.php/index.php, inside the code block that outputs the <applet> tag: echo("<param name=\"show controls\" value=\"yes\" />\n"); Future modifications regard networking support; this support will be integrated in the Java applet, porting the necessary portions of VDE code into Java. This work will be further explained in Section Description of FLOZ algorithm Now that we ve described the functionalities of FLOZ, let s describe what happens exactly when someone starts an image, selecting it from the menu and clicking Load Image : 1. index.php verifies that the image selection (received by itself via a HTTP POST) is correct (doing an iteration on ZooImageList), 93

94 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web then performs VNCInstanceList->allocateVNC() with the data of the image and the selected keyboard mapping; 2. index.php generates a HTTP Location header pointing to display/ #, where # is the return value of allocatevnc(). This way, the browser redirects to display/?display=#. 3. display/index.php verifies that # is really allocated for a valid image, and that the client IP is the same that allocated #, then, if VNCInstanceList->getQEMUPID(#) is 0, runs qemu with these options (-kernel-kqemu could be replaced by -no-kqemu or omitted, depending on the image and USE_KQEMU): qemu -hda ZooImageList->currentFile() -usb -snapshot -boot c -k \ VNCInstanceList->getKeymap(#) -kernel-kqemu -net none -vnc # 4. If QEMU was launched in this invocation, display/index.php tries to match the command line with the output of ps x to find its PID, and invokes VNCInstanceList->setQEMUPID() accordingly. 5. The applet is shown, together with an <object> which loads keepalive.php (which, in turn, invokes VNCInstanceList->ping(#) every PING_INTERVAL seconds) If an exception is raised, the page that catches it shows descriptive information about it. Let s also see what happens when a image is killed using the Shutdown button: 1. display/index.php passes the Shutdown event and its display number (#) to index.php using POST. 2. index.php verifies that # is allocated and that the caller IP is the same that launched the image, then invokes VNCInstanceList>getQEMUPID(#) and verifyqemupid() on the returned PID. 3. index.php kills QEMU PID and invokes VNCInstanceList- >freevnc(#) Performance Having analyzed FLOZ displaying algorithm, it s time to say 94

95 Free Live OS Zoo: A Virtual Machine Support with Web access something about the performances of the system. Two points of view are distinguished here, the speed at which QEMU emulates the OS (that depends on the server) and the speed of screen rendering, keyboard and mouse response (that depends on the network) Emulation speed One of the main advantages of QEMU is its speed, made possible by its dynamic instruction translation. KQEMU (working with x86 host CPU) works with most images, and gives a speed very near to original system, with its direct execution of user code. Full virtualization support (-kernel-kqemu option), available for Linux target systems, executes all CPU code as user code; this way, emulated system is really as fast as without emulation. The only problem is that the target system clock is faster than the host system clock. This could be solved (partially, i.e. target system clock reaches its correct speed some time after the emulation start) by setting the host real time clock frequency with this command (as root): # echo 1024 > /proc/sys/dev/rtc/max-user-freq VNC speed VNC is a product of the thin client philosophy, which means it is designed to have good performances with little requirements. Nevertheless, QEMU VNC support is a relatively new feature, as said before, and remote visualization is not real time. However, with a DSL connection (1280 kbps) the latency is acceptable, about 0.5 seconds in text mode, 1 2 seconds in GUI with 800x600 resolution. Video mode changes could result in higher latencies. Mouse pointer has the same latency, but follows really well the host pointer, without losing its trail. In the early stages of development, it was tried to launch QEMU in a X VNC server and connect to it, but the mouse behavior inside QEMU window, while showing less latency, was really bad, with the pointer that very often took unexpected directions or reset its position. 95

96 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web FLOZ networking support A feature that distinguishes FLOZ from other similar systems is its networking support; not because it has it, but because this support is designed to deliver all traffic through the user network stack. This is a key security issue: if the emulated OS appears on the Internet with the IP of its user, then he has direct responsibility for whatever he does, and not the FLOZ provider. So, the provider doesn t need configuring firewalls on the server to filter OS traffic. This is done using VDE, the Virtual Distributed Ethernet software developed by Renzo Davoli. It is discussed in section ; in FLOZ, a vde_switch is launched on the server, and the OS image is run with vdeqemu connecting to that switch. On the client side, user is requested to run its own vde_switch and slirpvde and connect his switch to that on the server, using dpipe and SSH. Figure 3.2 shows a scheme of networking support. Figure 3.2: FLOZ networking support 96

97 Free Live OS Zoo: A Virtual Machine Support with Web access Now we have to see what modifications occur in the FLOZ algorithm when networking is enabled (the common.php constant that enables networking support is QEMU_USES_NETWORK). Let s begin with the starting of an image. 1. After the allocatevnc(), index.php runs vde_switch with the following syntax, then finds its PID and invokes setvdepid() accordingly (# is the display): vde_switch -m 777 -d -s /tmp/vde_ctl# 2. Instead of immediately redirecting to dispay/index.php, index.php outputs instructions for the user: he should run vde_switch -m 777 -d, and then slirpvde -d -D, which will give the emulated OS DHCP and DNS. Then he should run dpipe to connect the two switches, using the following syntax: dpipe ssh www-data@<server-ip> vde_plug /tmp/vde_ctl# = vde_plug Obviously, the user should have a way to authenticate as www-data on the server, like a SSH key previously stored in the server. After running dpipe, the user clicks on the link provided by index.php, which points to display/# as usual. 3. The command line for QEMU has two differences: the executable is now called vdeqemu, and the option -net none is replaced with -net nic -net vde,vlan=0,sock=/tmp/vde_ctl# 4. when vdeqemu starts, it runs another vdeqemu process with the same command line, only changing -net vde,... with -net tap,.... This new process is the real QEMU that runs the OS image, so FLOZ searches for and stores its PID. 5. This phase has no changes. Let s now see what happens to the image killing task. 1. This phase has no changes. 2. vdeqemu PID is verified instead of qemu PID, using verifyvdeqemupid(), and vde_switch PID is get using 97

98 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web VNCInstanceList->getVDEPID() and verified with verifyvdepid(). 3. also the server vde_switch is killed, and the files it created (/ tmp/vde_ctl# directory and /tmp/vde_ctl#.* files) are deleted. The user dpipe process terminates, while his vde_switch and slirpvde are still in execution and could serve another image. The speed of this emulated network is obviously limited by that of the connection between the client and the server. The overhead generated by VDE, slirpvde and SSH could slow down the connection a bit Security As said in section 3.1.5, there are some security issues with the version of FLOZ discussed here. The VNC traffic is not encrypted, and the IP check made at application level by PHP doesn t prevent anyone from manually connecting to the VNC port opened by qemu, or to the vde_switch. Future development will address these issues; section 4.1 focuses on the first two, while the latter is discussed during section

99 4 FUTURE DEVELOPMENTS FOR FLOZ I don t know the future. I didn t come here to tell you how this is going to end. I came here to tell you how it s going to begin. NEO, THE MATRIX Due to time limitations, FLOZ is a project still in the early phase of its development, so the work on it won t be over with this thesis. There are some features that were thought about from the beginning of this project and aren t still implemented, and other ideas that came out during development. Let s see them in detail, starting with the security issues pointed out in sections and VNC traffic encryption and connection control The original VNC specification does not enforce the use of encryption techniques to protect data sent by the client (keyboard typing and mouse movement) and the server (keyboard and mouse feedback, screen updates). This means, if such techniques aren t used, that anyone can intercept the connection and watch its content, or do man in the middle attacks, i.e. to send forged input data to the server and returning forged output to the client. This way the attacker could also eavesdrop any sensitive information sent, such as passwords, credit card numbers, personal data and so on. The gravity of this issue could depend of the use made of the VNC connection, in particular on what network connection is established between the client and the server. A LAN connection should probably be less vulnerable to attackers than a Internet connection, especially if the LAN is not connected to the Internet itself. However, without a specific protection for the VNC connection, we can t assume so much 99

100 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web about the security of what surrounds it. Even an application designed for testing purposes, like FLOZ, needs something more on this front; e.g. if the user wants to test networking support doing a SSH connection from the emulated OS and he doesn t have an authentication key he should probably drop its attempt, to protect his password from being stolen. As RealVNC FAQ says68, The only completely secure computer is one without a network. If a computer does have a network connection, then it is only as secure as its weakest point. From the point of view of VNC, it is needed to make its data transfer secure to avoid it being the weakest point. RealVNC version 4 has support for strong security in its Personal and Enterprise editions. They use 2048 bit RSA for server authentication, and 128 bit AES for session encryption. These editions are proprietary products, so their code isn t published and can t be reused into FLOZ; however, the protocols used are good suggestions for our purposes. AES is also used by a Internet accessible VM support, Workspot (see section 2.5.3). The Free edition of RealVNC (whose code is released under GPL), version 3 of RealVNC and current version of TightVNC don t provide support for these security protocols, but only implement a DES challenge response protocol for authentication, with passwords limited to 8 characters. This is obviously a weak security framework: the session data are still unencrypted, the maximum password length (64 bit) and the protocol used (which has 56 bit keys) are very vulnerable to brute force attacks, and nowadays every secure connection framework (like OpenSSL) use stronger algorithms not only for authentication, but for session encryption itself. Current QEMU VNC support, moreover, does not support even the authentication scheme, so FLOZ displaying system is totally insecure. Current FLOZ suffers from another security problem: once QEMU is started, it opens a port on the server, to which everyone can connect

101 Future developments for FLOZ and view/interact with the emulated OS. This is also a grave bug, but fortunately it s easy to solve: FLOZ could access local firewall rules to restrict the access to a VNC port for the IP that run the OS image. So the IP is now checked at its own level of the networking stack. There are basically two ways to solve the traffic security problem. The first one is to encapsulate the VNC session in a secure tunnel, exactly like in the networking support. For example, if the user has SSH access to the server, he could connect making a forward of its local port to the server port 5901 (if FLOZ allocated display 1 for him). For the Linux version, the command line is $ ssh -L 25901:localhost:5901 user@host This command assumes that host is the FLOZ server. If it isn t so, localhost should be replaced by the server host name. Again, if every client connects to the same SSH server, this solution still permits anyone with SSH access to get the same port, and since all users connect to the same port (SSH server port, usually 22) it s not possible to filter IP at transport level. This issue could be solved using another secure channel that opens one channel port per user (exactly like VNC does), and it will be discussed again in the next session. The other way, probably more effective, is to implement security on both sides of the VNC connection: the QEMU VNC server and the VNC viewer applet. First of all, it should be clarified if we want only session encryption or also a password based authentication. The latter is, maybe, not necessary, as there are two ways to ensure the identity of the caller: 1. The encrypted QEMU VNC server could open TCP ports in the same way as the unencrypted version, so a transport level IP filtering is now possible. 2. The applet code downloaded by the browser (VncViewer.jar) could be generated on the fly at every request, embedding into it the key for session encryption. This way, also NATed IPs could have exclusivity warranties in accessing 101

102 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web QEMU VNC server. The second policy requires to create a new JAR for every allocated display. This could be done in two ways; the first one is to create temporary JARs with specific names (e.g. VncViewer-#.jar, where # is the display number) and remove them on machine shutdown, while the second one is to make the JAR URL actually point to a PHP page which gets the display number as input (e.g. using VncViewer?display=1 as URL) and returns the correct JAR for that display. In the first case the applet code is generated once; in the second case, since JVMs usually do not download applet code more than once until they are restarted, the applet code is regenerated only in the case of a browser or JVM crash/exit, and not if the page is simply reloaded. The second policy and session encryption lock access to the VNC port to other VNC clients. This is a trade off between security and compatibility, because the compatible protocol is not secure, so the secure protocol must be less compatible. To provide at least the displaying support to those having problems with their JVM and/or browser plugin, a VNC viewer with session encryption could also be developed, and compiled on the fly with the encryption key to implement the policy discussed above. Regarding session encryption, a symmetric key scheme is faster than an asymmetric one, and sufficiently secure for the purpose. Good choices are AES, the Rijndael algorithm chosen by NIST in 2000 [SchWhi2000] as the standard for U.S. government, also adopted by IETF [Cho2002] for the Transport Layer Security (TLS); Blowfish, widely used in the industry, faster than AES especially with long keys; Twofish, less widely spread than Blowfish but generally regarded as faster and of superior quality. In general, the importance of VNC traffic encryption in FLOZ depends on what use should be made of FLOZ itself. For testing and learning purposes (which are the purposes FreeOsZoo was thought for), a lower lever of security could be acceptable, while on a production environment it is not to be suggested. 102

103 Future developments for FLOZ 4.2 Client side networking inside Java applet The current networking support of FLOZ is unsatisfactory in many ways. First of all, it requires some software to be installed on the client machine, software that is not suitable for all operating systems. Moreover, the software used to create the secure channel (SSH) is probably a bit over sized for the purpose, and gives problems because all clients connect to the same port, so it s difficult to create transport level IP filtering to ensure that only the IP which launched the image could use its network. VDE itself is more than the user needs; it is not necessary a vde_switch on the client side, but only the plug that connects to the other end of the double pipe and the slirpvde process that regenerates TCP/UDP packets and provides DNS and DHCP to the image. The best way to achieve the desired result is the same as in the previous section: to port client side networking directly into the Java applet. This means that the applet should create the secure connection to the vde_switch on the server side, act as DHCP and DNS server for the emulated OS, regenerate TCP/UDP packets and send them to the host network routes. This way, the user needs only the applet code to get both the displaying system and the networking support. Figure 4.1 shows how FLOZ networking support changes. Now there is no vde_switch on the client side, and the vde_plug and slirpvde are embedded in the applet itself. This could be done because vde_switch does nothing on the Ethernet packets it receives, but only routes them to the correct destination according to the MAC address, like a real Ethernet switch does. The applet, in fact, also implements the double pipe and its secure channel; this means that it makes a connection to the server side of the secure channel and runs the plug that connects to the server side vde_switch. Once the connection is established, the applet could start to receive Ethernet traffic which will be passed to the embedded slirpvde. 103

104 Zoo di sistemi operativi: supporto di macchine virtuali con accesso via Web A dedicated secure channel: vde_cryptcab Figure 4.1: FLOZ embedded client side networking Before watching the connection algorithm in detail, let s see what features should the secure channel have. Since the channel is developed for this particular kind of connection, we could embed in it exactly the features we want. First of all, we have to answer the same question of section 4.1: do we need either confidentiality (connection encryption) and authentication (via password, key or something like that) or the former is sufficient? The answer is the same: we could implement encryption and do simple checks for authentication, doing IP filtering and embedding the encryption key in the applet source code. A server instance is started when a display is allocated and listens on a single port, allowing access to a single IP. The discussion made in Section 4.1 about session encryption protocol is still valid here: a symmetric scheme is faster, and the choice 104