Zoo di sistemi operativi: supporto di macchine virtuali...

ALMA MATER STUDIORUMUNIVERSITÀ DI BOLOGNA

Facoltà di Scienze Matematiche, Fisiche e NaturaliCorso 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: Relatore:Mattia Gentilini Renzo Davoli

I Sessione

Anno Accademico 2005/2006

© 2006 Mattia Gentilini. Alcuni diritti riservati.

Questo testo è distribuibile liberamente secondo la licenza Creative Commons AttribuzioneCondividi allo stesso modo 2.5 Italia. La versione più aggiornata di questo testo è disponibile per il download dal sito http://www.mg55.net/tesi .

© 2006 Mattia Gentilini. Some rights reserved.

This text is freely distributable under the terms of the Creative Commons AttributionShare Alike 2.5 Italy license. An updated version of this text is available for download at http://www.mg55.net/tesi .

http://creativecommons.org/licenses/by-sa/2.5/it/


http://www.mg55.net/tesi



http://www.mg55.net/tesi

Perception: Our dayin, dayout world is real. Reality: That world is a hoax, an elaborate deception spun

by allpowerful machines of artificial intelligence that control

us. Whoa.

–TAGLINE PER I POSTER DI “THE MATRIX”

Sommario1 Introduzione..................................................................................................52 Zoo di sistemi operativi: Idea e scenario..................................................9

2.1 Motivazioni e vantaggi dello zoo......................................................102.2 Storia e classificazioni dei sistemi di emulazione...........................13

2.2.1 Breve storia.................................................................................................152.2.2 Classificazione delle macchine virtuali..................................................16

2.2.2.1 La classificazione secondo Virtual Square....................................172.2.2.2 La classificazione secondo Smith e Nair........................................19

2.3 Esempi di emulazione.........................................................................202.3.1 Macchine virtuali complete.....................................................................21

2.3.1.1 QEMU.................................................................................................212.3.1.2 VMware..............................................................................................262.3.1.3 Microsoft Virtual PC e Virtual Server............................................272.3.1.4 PearPC................................................................................................282.3.1.5 MaconLinux....................................................................................28

2.3.2 Macchine paravirtuali complete.............................................................282.3.2.1 Xen.......................................................................................................302.3.2.2 Denali..................................................................................................30

2.3.3 Virtualizzazione del sistema operativo..................................................312.3.3.1 UserMode Linux..............................................................................322.3.3.2 Virtuozzo e OpenVZ.........................................................................332.3.3.3 Linux VServer....................................................................................34

2.3.4 Virtualizzazione a livello di processo....................................................352.3.4.1 Virtualizzazione di rete: VDE (Virtual Distributed Ethernet)....362.3.4.2 Virtualizzazione di rete: Ale4NET..................................................412.3.4.3 Virtualizzazione di file system........................................................422.3.4.4 Virtualizzazione di CPU: Apple Rosetta e Universal Binary.....452.3.4.5 Virtualizzazione generale: ViewOS/UMView............................47

2.3.5 Virtualizzazione di linguaggio di programmazione............................492.3.5.1 Java......................................................................................................502.3.5.2 CORBA (Common Object Request Broker Architecture)............542.3.5.3 Microsoft .NET..................................................................................54

2.4 Network Computing...........................................................................562.4.1 VNC (Virtual Network Computing)......................................................582.4.2 Windows Terminal Services....................................................................612.4.3 NX Technology..........................................................................................62

2.5 Esempi di sistemi di test per OS accessibili da Internet.................632.5.1 HP Test Drive.............................................................................................642.5.2 Linuxzoo.....................................................................................................642.5.3 Workspot....................................................................................................66

3 Free Live OS Zoo: A Virtual Machine Support with Web access.....673.1 User Manual.........................................................................................67

3.1.1 Introduction...............................................................................................673.1.2 Requirements.............................................................................................683.1.3 Usage without networking......................................................................69

5

3.1.4 Usage with networking............................................................................703.1.5 Known issues.............................................................................................70

3.2 Provider Manual..................................................................................713.2.1 Introduction...............................................................................................713.2.2 Requirements.............................................................................................723.2.3 Installation..................................................................................................73

3.2.3.1 The public files..................................................................................733.2.3.2 The management scripts..................................................................763.2.3.3 Networking........................................................................................76

3.2.4 Customization............................................................................................773.2.4.1 Configuration constants...................................................................773.2.4.2 Managing images..............................................................................78

3.3 FLOZ Internals.....................................................................................783.3.1 The images..................................................................................................793.3.2 FLOZ backend: QEMU VNC server......................................................813.3.3 FLOZ frontend: PHP and Java applet...................................................82

3.3.3.1 PHP and XML....................................................................................823.3.3.2 ZooImageList class............................................................................833.3.3.3 VNCInstanceList class......................................................................843.3.3.4 common.php: verifyPID() functions..............................................873.3.3.5 common.php: web standards and browser compatibility..........873.3.3.6 The Java applet..................................................................................89

3.3.4 Description of FLOZ algorithm...............................................................893.3.5 Performance...............................................................................................90

3.3.5.1 Emulation speed................................................................................913.3.5.2 VNC speed.........................................................................................91

3.3.6 FLOZ networking support.......................................................................913.3.7 Security.......................................................................................................94

4 Future developments for FLOZ...............................................................954.1 VNC traffic encryption and connection control..............................954.2 Clientside networking inside Java applet.......................................99

4.2.1 A dedicated secure channel: vde_cryptcab.........................................1004.2.2 The improved networking algorithm...................................................1024.2.3 Considerations.........................................................................................103

4.3 Imagetoimage networking.............................................................1044.4 Usercustomizable images................................................................1064.5 Multiuser access to images..............................................................1074.6 Load management policies...............................................................109

5 Conclusioni................................................................................................113Bibliografia...................................................................................................117Ringraziamenti.............................................................................................121

6

1 INTRODUZIONE

Mia madre non aveva poi sbagliatoa 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

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 1981. 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 http://www.seasip.demon.co.uk/Cpm/

8

http://www.seasip.demon.co.uk/Cpm/

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


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

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ù generalpurpose 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 realtime.

Anche gli animali vivono in ambienti diversi, devono fare cose diverse (chi volare, chi nuotare, chi correre), hanno sviluppato il corpo

11


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 animalisistemi 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 zooTanti 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).

4 http://www.oszoo.org/

12

http://www.oszoo.org/

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 30.000 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


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 2.3.1.1), 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


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


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


questo lavoro di tesi.

2.2.1 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 timesharing.

VM/370 viene definito un sistema di timesharing “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


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 pSystem5, 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 pSystem.

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 2.3.5 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.

2.2.2 Classificazione delle macchine virtuali

Come accennato, tante sono le possibilità ad oggi disponibili di emulazione, per questo si rende necessario definire una tassonomia.

5 http://en.wikipedia.org/UCSD_p-System . pSystem sarà uno dei tre OS supportati da IBM per il suo PC, insieme a CP/M86 di Digital Research e DOS di Microsoft.

18

http://en.wikipedia.org/UCSD_p-System


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.

2.2.2.1 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 istruzionimacchina 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


● 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 adhoc 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


● 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.

2.2.2.2 La classificazione secondo Smith e Nair

Per capire questo tipo di classificazione [SmiNai2005] bisogna

21


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 emulazioneViene ora presentata una carrellata di sistemi di emulazione.

Questa carrellata ha due scopi principali: mostrare con esempi concreti

22


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.

2.3.1 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.

2.3.1.1 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

6 http://www.qemu.org/7 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

http://www.qemu.org/


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


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 12. 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


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), CopyonWrite (o cow, usato da User Mode Linux), cloop (immagini CDROM compresse, come quelle della distribuzione Linux Knoppix) o qcow, versione speciale di CopyonWrite 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 CLGD 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

8 http://www.iaik.tu-graz.ac.at/research/krypto/AES/9 http://www.zlib.net/10 http://bochs.sourceforge.net/

26

http://bochs.sourceforge.net/

http://www.zlib.net/

http://www.iaik.tu-graz.ac.at/research/krypto/AES/


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 10.0.2.0, con 10.0.2.2 come gateway/DHCP e 10.0.2.3 come DNS. Per maggiori informazioni sul meccanismo di gestione delle connessioni, si legga la descrizione di slirpvde nella sezione 2.3.4.1, 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

11 http://slirp.sourceforge.net/12 http://vtun.sourceforge.net/tun/

27

http://vtun.sourceforge.net/tun/

http://slirp.sourceforge.net/


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 Usermode 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_64.

2.3.1.2 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 2.3.2.

13 Una lista è reperibile presso http://www.claunia.com/qemu/14 http://www.wmware.com/

28

http://www.wmware.com/

http://www.claunia.com/qemu/


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.

2.3.1.3 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.

15 http://www.microsoft.com/windows/virtualpc/16 http://www.microsoft.com/windowsserversystem/virtualserver/

29

http://www.microsoft.com/windowsserversystem/virtualserver/

http://www.microsoft.com/windows/virtualpc/


2.3.1.4 PearPC17

Passando al mondo Apple, PearPC è un emulatore di architettura PowerPC e si dichiara “architectureindependent”. Attualmente è in grado di funzionare sia su macchine little endian che su macchine big endian, con sistemi operativi POSIXX11 (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.

2.3.1.5 MaconLinux18

A differenza di PearPC, MaconLinux è 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. MaconLinux 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.

2.3.2 Macchine paravirtuali complete

Un sistema che attualmente sta riprendendo mercato tra le macchine virtuali è quello della cosiddetta paravirtualizzazione. Il

17 http://pearpc.sourceforge.net/18 http://maconlinux.org/

30

http://maconlinux.org/

http://pearpc.sourceforge.net/


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


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.

2.3.2.1 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).

2.3.2.2 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].

19 http://www.xensource.org/20 http://denali.cs.washington.edu/

32

http://denali.cs.washington.edu/

http://www.xensource.org/


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.

2.3.3 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


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.

2.3.3.1 UserMode 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 usermode; 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

21 http://user-mode-linux.sourceforge.net/

34

http://user-mode-linux.sourceforge.net/


verso il sistema reale le chiamate VFS.

Secondo la tassonomia SmithNair 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.

2.3.3.2 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 UserMode 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

22 http://www.swsoft.com/en/products/virtuozzo/23 http://openvz.org/

35

http://openvz.org/

http://www.swsoft.com/en/products/virtuozzo/


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).

2.3.3.3 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

24 http://linux-vserver.org/

36

http://linux-vserver.org/


legata al proprio livello di astrazione secondo SmithNair, una virtualizzazione completa, invasiva e con intercettazione delle syscall secondo Virtual Square.

2.3.4 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, ViewOS/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


virtuale né un ambiente separato, ma un’unica nuova visione. Questi limiti sono superati nel progetto ViewOS.

2.3.4.1 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

25 http://vde.sourceforge.net/

38

http://vde.sourceforge.net/


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


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 4.2.1.

wirefilter. È uno strumento di corredo a VDE, utile per emulare

40


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


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


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


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.

2.3.4.2 Virtualizzazione di rete: Ale4NET26

Si tratta di un progetto concluso, confluito dentro ViewOS, 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.

2.3.4.3 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

26 http://ale4net.sourceforge.net/

44

http://ale4net.sourceforge.net/


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 setuserid 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 2.6.15, 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(), ...);

27 http://fuse.sourceforge.net/

45

http://fuse.sourceforge.net/


● 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 2.3.4.5)

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:

28 http://www.filesystems.org/project-unionfs.html

46

http://www.filesystems.org/project-unionfs.html


● 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.

2.3.4.4 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

29 http://www.apple.com/rosetta/30 http://www.apple.com/universal/

47

http://www.apple.com/universal/

http://www.apple.com/rosetta/


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 68000 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

31 http://en.wikipedia.org/wiki/Universal_binary32 http://en.wikipedia.org/wiki/Fat_binary33 http://en.wikipedia.org/wiki/Rosetta_%28software%29

48

http://en.wikipedia.org/wiki/Rosetta_(software)

http://en.wikipedia.org/wiki/Fat_binary

http://en.wikipedia.org/wiki/Universal_binary


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.

2.3.4.5 Virtualizzazione generale: ViewOS/UMView34

A conclusione di questa carrellata delle virtualizzazioni a livello di processo, si esaminerà ora ViewOS, un altro progetto Virtual Square che si pone l’obiettivo di dare ad ogni processo attivo su una macchina una visione diversa del sistema.

ViewOS, 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 ViewOS si vuole [Gar2006, Gas2006]:

● Poter ridefinire system call e introdurne di nuove, mantenendo l’interfaccia di quelle esistenti per garantire

34 http://savannah.nongnu.org/projects/view-os

49

http://savannah.nongnu.org/projects/view-os


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 ViewOS 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”.

● Prototipazione: si può estendere, con minori costi

50


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.

ViewOS 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 ViewOS, con il nome di UMView.

● Integrando ViewOS 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


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, UMLWIPv6, 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].

2.3.5 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

35 http://www.sics.se/~adam/lwip/

52

http://www.sics.se/~adam/lwip/


stesse.

Verranno brevemente mostrati tre esempi che realizzano entrambe le definizioni di portabilità: Java, interessante per il proprio supporto ad applicazioni Webbased, 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.

2.3.5.1 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 pSystem. 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 settop 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 Webbased aveva le stesse richieste (codice leggero, sicuro, affidabile ed indipendente dalla piattaforma) del sistema per settop box di Time Warner. Per questo motivo Oak fu ripreso e modificato in Java, rilasciato nel 1995.

Gli obiettivi di progetto di Java [GosMcG1996] sono:

36 http://java.sun.com/37 http://en.wikipedia.org/wiki/Mesa_programming_language

53

http://en.wikipedia.org/wiki/Mesa_programming_language

http://java.sun.com/


● 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 runtime; inoltre il garbage collector lavora come processo a bassa priorità, ed è possibile ricompilare in codice macchina le applicazioni con alte richieste di computazione.

54


● 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 serverbased (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


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 (ObjectRelational 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.

2.3.5.2 CORBA38 (Common Object Request Broker Architecture)

È un sistema vendorindependent 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 metalinguaggio 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

38 http://www.corba.org/

56

http://www.corba.org/


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.

2.3.5.3 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

39 http://msdn.microsoft.com/netframework/40 http://en.wikipedia.org/wiki/Component_Object_Model

57

http://en.wikipedia.org/wiki/Component_Object_Model

http://msdn.microsoft.com/netframework/


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 (MarshalByReference) o per copia locale (MarshalByValue: 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 Windowscentered, che necessita l’uso di sistemi operativi Microsoft per essere utilizzato, almeno dalle applicazioni server, mentre lo standard OMG è stato progettato per essere architectureindependent.

2.4 Network ComputingViene 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

41 http://en.wikipedia.org/wiki/.NET_Framework

58

http://en.wikipedia.org/wiki/.NET_Framework


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 timesharing [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 webbased.

Commercialmente il sistema degli ASP è stato un disastro, finendo nella bolla speculativa delle dotcom 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


le prestazioni e l’interattività di un applicazione Webbased 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 nonacquisto 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 peertopeer 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 locationtransparent 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


sfruttare. Verranno qui discusse le caratteristiche di tre sistemi, con riguardo anche all’accessibilità via Web, requisito centrale per questo lavoro di tesi.

2.4.1 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 ultrathinclient, 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


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

42 http://realvnc.com/43 http://www.tightvnc.com/

62

http://www.tightvnc.com/

http://realvnc.com/


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.

2.4.2 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

44 http://support.microsoft.com/default.aspx?scid=kb;EN-US;q186607

63

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q186607


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.

2.4.3 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

45 http://www.rdesktop.org/46 http://www.nomachine.com/47 http://freenx.berlios.de/

64

http://freenx.berlios.de/

http://www.nomachine.com/

http://www.rdesktop.org/


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 roundtrip 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

48 http://en.wikipedia.org/wiki/NX_technology#Clients

65

http://en.wikipedia.org/wiki/NX_technology#Clients


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.

2.5.1 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 HPUX), Linux e BSD. È disponibile anche il test di una soluzione di clustering (OpenVMS Galaxy Cluster) o di un database (Oracle RDB).

49 http://www.testdrive.hp.com/

66

http://www.testdrive.hp.com/


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à.

2.5.2 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 Usermode 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

50 http://linuxzoo.net/

67

http://linuxzoo.net/


(/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.

2.5.3 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 noprofit, fornisce (tramite sottoscrizione, i cui proventi dovrebbero essere destinati allo sviluppo di Workspot stesso) accesso a server Redhat e Mandrake con X, tramite sessione

51 http://www.workspot.com/

68

http://www.workspot.com/


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 20032004. 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

3 FREE LIVE OS ZOO: A VIRTUAL MACHINE SUPPORT WITH WEB ACCESS

What is the Matrix? Control. The Matrix is a computergenerated

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 ManualThis is a short tutorial for users of FLOZ, the Free Live OS Zoo.

3.1.1 Introduction

Free Live OS Zoo (FLOZ) is a Webbased OS emulation project,

52 http://www.oszoo.org/

71

http://www.oszoo.org/


aimed at giving everyone the opportunity to test any FLOSS53 Operating System simply using a Web Browser. FLOZ is designed to be easytouse 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.

3.1.2 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

53 Free/Libre/Open Source Software54 http://java.com/download/55 http://www.apple.com/java/56 Due to limitations in Rosetta (see section 2.3.4.4), you can’t run Java applets in a

PowerPC browser for MacOS X on a Intelbased Mac, even if the JVM is Universal Binary. Use a Universal Binary browser (Universal versions of Safari and Camino are available).

57 http://www.blackdown.org/

72

http://www.blackdown.org/

http://www.apple.com/java/

http://java.com/download/

Free Live OS Zoo: A Virtual Machine Support with Web access

version is 1.3 or later for nonSun 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.

3.1.3 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 http://www.oszoo.org/index.php/FLOZ

73

http://www.oszoo.org/index.php/FLOZ


3.1.4 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 VDE259 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 3.1.3. 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 3.1.3 for more information.

3.1.5 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

59 http://sourceforge.net/projects/vde/60 Network Interface Card

74

http://sourceforge.net/projects/vde/


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 ManualThis is a guide to help installing and configuring FLOZ, to make it

available to end users.

3.2.1 Introduction

For an introduction to FLOZ in general, see Section 3.1.1. 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

61 http://cm.bell-labs.com/plan9/

75

http://cm.bell-labs.com/plan9/


OS image output and send input to it.

3.2.2 Requirements

These are the hardware & software needs of FLOZ:

● A x86, x86_64 or PowerPCbased computer connected to the Internet.

○ Recommended connection: broadband (T1 or better)

○ Recommended processor: x86_64 multiple processors or multicore processor (AMD Athlon 64 X2, FX60, 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 59015999 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 Bournecompatible 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 prepackaged 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. 0.8.1 or later, and (optionally) KQEMU ver. 1.3.0pre7 or later. The configure program will remember you not

62 http://qemu.org/status.html

76


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 250 0

● (For networking support only) VDE 2.0.2 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.

3.2.3 Installation

3.2.3.1 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


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


File name Perms Description

index.php r-- Homepage, with image and keyboard selection.

keepAlive.php r-- “Pings” active images while used.killOldImages.php*64 --- 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 of QEMU

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 of VDE

launches/killings.vnclist.php r-- Class VNCInstanceList to manage

available displays.vnclist.xsl r-- XSL Transformation to show used

displays, for debugging.webps.php65 --- Shows humanreadable 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.

64 Scripts with * MUST NOT be in a Webaccessible 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


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.

3.2.3.2 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 superuser access, you could put the cron job in the systemwide 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 frontend to usedvnc.xml, showing active QEMU and VDE processes and informations about allocated displays.

3.2.3.3 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


without typing passwords.

3.2.4 Customization

3.2.4.1 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 http://HOST_WEB/ the site URL.

VNC_FIRST_DISPLAYVNC_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


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.

3.2.4.2 Managing images

If you point your browser to http://HOST_WEB/zoomanage 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 reenable it, click “Enable image”.

3.3 FLOZ InternalsFLOZ is, in fact, a Web frontend to QEMU. Its purpose is to get a

82


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 browsercompatible and standardscompliant 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.

3.3.1 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


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 textmode 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


available on Free OS Zoo, to make single copies of the images themselves, suitable for both live testing and downloading.

3.3.2 FLOZ backend: QEMU VNC server

The core of FLOZ is QEMU and its VNC interface. QEMU was discussed in Section 2.3.1.1, and VNC in 2.4.1. 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 2004.

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 (5900 + 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


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.

3.3.3 FLOZ frontend: PHP and Java applet

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 frontend/backend scheme is shown in Figure 3.1.

86

Figure 3.1: FLOZ displaying system


3.3.3.1 PHP and XML

Let’s start with PHP67 (PHP: Hypertext Preprocessor). It is a generalpurpose 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 nonproprietary declarative metamarkup language, i.e. it allows to define markup, its formal syntax and also its semantics. It’s designed to be human and machineunderstandable, 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 stylesheeting (XSL and XSLT).

3.3.3.2 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.

67 http://www.php.net/

87

http://www.php.net/


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 method, returns the size of image list.

rewind();next();boolean valid();DomNode current();int key();

Iterator 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.

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.

zoomanage.php is the Web frontend 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


3.3.3.3 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


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() called for an unused display), using the Exception class

90


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.

3.3.3.4 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 verifyPID(string regexp, int pid, int display, string

dOption) executes a ps x command (or ps 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


3.3.3.5 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 DescriptionstartPage() <?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_rev(), link_common(), meta(), meta_http(), meta_common()

<link />s and <meta />s for <head>

functions from TB() to badbrowserIDX()

Browser recognition, to adapt generated code to it.

top() Makes a “^ top” link, for long pages.br(), strBr(), hr(), strHr(), cmempty(), strCMEmpty()

<br /> and <hr />. cmempty() controls the / at the end of empty elements.

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


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 Mozillacompatible browsers. So it’s impossible to have a XHTML 1.1 compliant output for every browser that supports it.

3.3.3.6 The Java applet

The Java applet of TightVNC and its connection protocol are dealt with in section 2.4.1. 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 reenabled 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 4.2.

3.3.4 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


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(#).

3.3.5 Performance

Having analyzed FLOZ displaying algorithm, it’s time to say

94


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).

3.3.5.1 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

3.3.5.2 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, 12 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


3.3.6 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 2.3.4.1; 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.

96

Figure 3.2: FLOZ networking support


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


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.

3.3.7 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 4.2.

98

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 3.1.5 and 3.3.7.

4.1 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 maninthemiddle 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


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 2048bit RSA for server authentication, and 128bit 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 Internetaccessible 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 challengeresponse 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 56bit keys) are very vulnerable to bruteforce 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

68 http://realvnc.com/faq.html

100

http://realvnc.com/faq.html

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 25901 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 passwordbased 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 transportlevel IP filtering is now possible.

2. The applet code downloaded by the browser (VncViewer.jar) could be generated onthefly at every request, embedding into it the key for session encryption. This way, also NATed IPs could have exclusivity warranties in accessing

101


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 tradeoff 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 onthefly with the encryption key to implement the policy discussed above.

Regarding session encryption, a symmetrickey 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


4.2 Clientside networking inside Java appletThe 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 “oversized” for the purpose, and gives problems because all clients connect to the same port, so it’s difficult to create transportlevel 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 clientside 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 serverside vde_switch. Once the connection is established, the applet could start to receive Ethernet traffic which will be passed to the embedded slirpvde.

103


4.2.1 A dedicated secure channel: vde_cryptcab

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

Figure 4.1: FLOZ embedded clientside networking


should be between Blowfish, Twofish and AES. The channel could also embed the dpipe and vde_plug on both sides; this means that the applet connects to the vde_switch socket and, once connection is established, the applet sends and receives Ethernet packets and the server passes them to the switch.

A channel that meets many of the requirements needed is vde_cryptcab, a project for a secure VDE channel. It is scheduled to be released with VDE 2.1.0, currently in release candidate state, together with libvdeplug, a library implementation of vde_plug that can be used directly from the source code of other VDE components (slirpvde, vde_switch, vde_cryptcab, vdeqemu). vde_cryptcab, in particular, is developed by Daniele Lacamera.

The main difference between vde_cryptcab and SSH is at transport layer: vde_cryptcab uses UDP instead of TCP. This is better for VDE, especially when a TCP session is carried on the virtual Ethernet and one packet of the channel connection is lost. In this case, if SSH or any other TCP channel is used, the fast recovery mechanisms of the two TCP sessions both try to send their packet again, interfering with each other and provoking notable losses in connection speed. If the channel uses UDP, like vde_cryptcab does, only the carried TCP connection activates its retransmission algorithms, and there is less traffic overhead. So, vde_cryptcab is a good choice for network performance.

From the security point of view, a datagram network application is more prone to packet duplication attacks. vde_cryptcab addresses this issue by using a global variable, mycounter, initialized to 1; when a datagram is sent, mycounter is put into the datagram payload, and then incremented. On datagram reception, the received counter value is compared to the connection current value; if the received value is greater, the connection counter is set to that value, otherwise a error is returned.

vde_cryptcab implements a clientserver connection, also embedding dpipe. The server runs the plug at its side of the connection (using libvdeplug) and listens on a chosen port; the client randomly

105


generates a Blowfish encryption key and sends it to the server with a SCP connection (this obviously requires that the client could authenticate via SSH to the server), then it runs the clientside plug and starts transmitting Ethernet traffic in both ways, encrypting it with the Blowfish key.

The main difference between vde_cryptcab and the channel that was described at the beginning of this subsection is the presence of a authentication, made with an external program; the use of authentication permits to have a single instance of vde_cryptcab server to serve all clients. To avoid the use of external programs and embed everything into the applet, vde_cryptcab could be modified to remove authentication, and then run one instance of the server for every display allocated.

4.2.2 The improved networking algorithm

Assuming that vde_cryptcab was modified as described above, we could now describe what should be the behavior of this improved FLOZ, when a image is run (as usual, # is the number of the allocated display):

1. index.php launches vde_switch and the vde_cryptcab server, listening on port (8900 + #), and redirects the browser to display/index.php (the <display> element should now keep track of vde_cryptcab PID, too)

2. display/index.php does the usual IP verification and then creates the encryption key, embeds it in the applet and sends applet code to the client (using JAR naming or a specific PHP JAR generator, as discussed in section 4.1); it also launches vdeqemu, connected to the vde_switch of phase 1.

3. The applet starts; it provides access to the vdeqemu VNC port, connects to the vde_cryptcab server, gets the host DNS server address, to send it DNS queries, and gets the host route, to send packets through the Internet.

106


4. The server verifies the IP and the encryption key of the client, then starts sending and receiving Ethernet packets.

5. When the applet receives a DHCP request, it does the usual configuration protocol (DiscoverOfferRequestAck) giving the host OS an address in the subnet 10.0.2.0, setting default route to 10.0.2.2 and DNS to 10.0.2.3 .

6. Now the Ethernet packets received by the applet via vde_cryptcab (except periodical DHCP lease renewals) are opened to rebuild the TCP or UDP packets, which are reencapsulated with NAT and sent to the local route; packets received from the host network are opened to get the level 4 payload and encapsulate it in Ethernet packets for the emulated OS.

As said in section 4.1, if the applet code is generated on request by PHP, it is regenerated (with a new encryption key) only if the JVM is restarted.

4.2.3 Considerations

The porting of clientside networking into the Java applet is the most important development scheduled to be done on FLOZ, since it could make emulated OSes really “usable” without modifying the base requirements: a browser, a JVM, a DSL or faster connection to the server. The port can obviously raise some issues, basically about what Java classes are to be used to implement the various data structures and functions used by the C code of VDE. It is to be understood whether it is better to use the basic data types of Java (byte, boolean, int, char, long...) or their class wrappers (Byte, Boolean, Integer, Character, Long...), and if a data type in C is used for its semantics (e.g. a char[] used for a string could become a String) or for its size (e.g. a char[] used to have a array of 8bit items could become a byte[]). Plus, the network primitives are slightly different, especially regarding address structures and conversions. Moreover, some things could require a lot of code in C and a few lines in Java, and viceversa. More generally, VDE code is made

107


for POSIX compliant systems, with a particular focus on Linux, while Java code should be portable and cannot make assumptions on the architecture underlying the JVM. This should be the major challenge.

One good thing in this work is that VDE, like FLOZ, is a project inspired by Renzo Davoli, and his fellow developers are students or guests in this Department, so it will be slightly easy to get feedback from them.

4.3 Imagetoimage networkingAnother possible development is to permit network connections

between the OS images. This means that, in addition (or as an alternative) to the NIC connected to the user network stack, the OS could also connect to other OSes running on the same server. This could be done in many ways; first of all, it has to be decided what policy will be used for OS network access, i.e. what connections can a OS do.

A possible way is to run the OS image with two NICs, one connected to the user network stack (using the secure tunnel and slirpvde or the Java applet) and the other one connected to a common vde_switch on the server. This way every image could access either the Internet and all other images; this also means that a OS image could access the Internet also through the networking stack of another client. So, this solution may be unacceptable for security reasons. However, a user warned about this before running the image could responsibly choose to connect to others or not.

It’s also possible to create more server vde_switches, to build up groups of images. Users could have 3 options: restrict their vde_switch only to their image, run a vde_switch that makes other images connect to their one, or connect to a vde_switch opened by other users. This way, a user could choose responsibly to open its connection to others. For this solution, it could be needed to implement some mechanism for notifying users who open access to their vde_switch of the presence of new clients that want to connect, to let them authorize these

108


connections or not. For this purpose, a clientside application is needed, such as Javascript or an extension of the applet.

A further improvement could be to let the user activate and connect to multiple vde_switches, to emulate some kinds of real networks (e.g. bridging, NAT, tunnels). This is basically the same as using one switch, it’s only to be ensured that every image connects to at most one DHCP. This feature and the former require a networking configuration dialog to be added to FLOZ interface.

Local networking requires OS network configuration. If there is only a server switch and all images are connected to their user’s network, users should manually configure the NIC connected to the switch to have a IP for that local connection. If there are more switches run on user request, every switch is connected either with multiple machines on the server and the client applet which provides Internet routing and DHCP to all of them; so, the images can connect to the Internet and communicate each other using the addresses given to them by the client DHCP.

Another issue raised by local networking is MAC address configuration. QEMU assigns a default MAC address to the NICs it creates, 52:54:00:12:34:56 (incremented for every NIC in the same image) As long as there is at most one image connected to every switch there is no problem, but when there are more images connected to the same switch it is necessary that they have different MACs. A possible address scheme could be 00:11:22:33:xx:yy, where xx is the display allocated and yy an incremental number for the NICs (both in hex), and the option to set it is -net nic,macaddr=00:11:22:33:xx:yy. Also, if more than one NIC is activated for a image, the option ,vlan=yy must be appended to -net specifications.

Local networking is an interesting extension to the testing possibilities of FLOZ, making it a good environment to study network management, firewalls, routing, or developing network applications. However, it’s better to implement this support after porting the client

109


side networking inside the Java applet.

4.4 Usercustomizable imagesThe improvements for FLOZ discussed above are suitable for any

environment in which FLOZ is used, because they are extensions desirable for any user or provider. This and the following extension are probably more desired for a “production” environment, in which the OS images are not simply used for testing, but for working, advanced learning, providing services. A production environment could usually provide more hardware and software resources, and this makes possible to do intensive use of “heavy” systems like FLOZ.

This section deals with the possibility for FLOZ users to have their own image, which they can customize, and whose state isn’t lost at shutdown. This way a user could keep the image updated, install new software, do everything he does on his computer. This obviously raises a series of issues.

First of all, a user should be assured that no one but him can modify his images. To do this, FLOZ must provide authentication and keep a user database which tracks the user settings and the images he has customized. User settings could be his real name and email address, street address, preferred keyboard mapping, and/or other relevant informations. The authentication could be made with HTTP or inside the applet; the first way is probably better, especially if HTTPS is used, because the entire session is encrypted and the keys for VNC (see section 4.1) and vde_cryptcab (see section 4.2) could then be sent in a secure connection. Authentication can still be avoided for those users that only want to test images without saving their state.

After authentication, a user could create its copy of one of the images available, or run one of the copies he made before. Whatever he chooses, he could set up networking and keyboard mapping before running the image. To implement this, FLOZ should keep a repository with all images, and one for each user with the copies he has made; in

110


the first one, images should be readable by www-data, while in the second they’d also be writable (authentication will ensure that only the owner can modify them). This requires a lot of hard disk space, that’s the one of the reasons why this improvement was categorized as “for a production environment” at the beginning of this section.

The possibility of making persistent modifications to the images raises some problems about fair use. Providers should choose the policy they prefer, keeping in mind that installing software without a license on the images could result in copyright infringement, for which also the provider could be legally persecuted. A provider could simply stress this, or be more radical and forbid any proprietary software, to preserve the “freedom” of FLOZ (the FLOZ GPL license does not force providers to do this); he could even make periodical checks of customized images, to ensure that the policies are followed by the users.

In professional environments, a FLOZ with customizable images could be useful for making virtual networks at low costs, for learning new OSes, for doing work everywhere with little requirements. The next step is to emulate a real network multiuser OS, and will be discussed in the next section.

4.5 Multiuser access to imagesProfessional environments could need to train their system

administrators or keep updated; system administrators could need to evaluate new users before making them use “costly” systems, e.g. expensive hardware/software with expensive supporting; system administrators could need to test new software solutions in conditions as close to real ones as possible, installing the less software possible.

These needs require a complete emulation of a real system, and FLOZ lacks multiuser support. Adding multiuser support to FLOZ raises some issues, let’s see what they are.

When a user logs in to FLOZ, he now could not only starting or creating his images, but also login to other users’ images. It should be

111


assumed that the administrator of a OS image creates the account and communicates its login data to the user outside the FLOZ system. There can be two ways to manage the login of a user to an image administrated by another user: the first requires that the administrator creates both the account on the image and a access to that image for the corresponding FLOZ user, while the second permits FLOZ access to every image for any registered user, leaving user filtering to the image.

Before deciding what’s the best, it should be chosen what kind of access the users have. The easiest way is to give remote access only, letting only the administrator to run and shutdown the image; users could access trough remote shells (like telnet or SSH) from their own images, assuming that FLOZ imagetoimage networking support is present (see section 4.3). Another way is to allow local access also to users: the administrator runs the image, and the first one who connects to its VNC server could use the system just as a public terminal (do a graphical or tty login, change between virtual terminals, etc.). Moreover, administrators could allow users also to startup and shutdown the images: the first user who connects could startup and then login, like in the preceding option, and shutdown whenever he wants.

Remote access is difficult to be intercepted by FLOZ (it requires to analyze TCP/UDP payloads in the vde_switches, and different remote shells use different payloads), while it is easy to verify privileges for local access. So every registered FLOZ user could do remote access from another image, while the administrator will enable selected users to access also locally. Obviously, administrators could also block remote access inside the OS image, as they do on a real system, configuring firewall rules or remote shell server policies. Allowing users to startup and shutdown images is probably not desired in a professional environment, but can be useful to allow multiple administrators for a single image. So different access levels are implemented: all FLOZ users could do remote access, some users have local access, some of them are also administrators and could run and shutdown the image. Every user

112


is administrator of its own images and could get local access or administration also for other images.

To prevent users to lock local access for a image for a long time, a usage timeout could also be implemented. After that time, the HTTPS session expires and any user could get the local access. It could also be implemented a maximum number of local accesses a user could have at the same time. These limits may not apply to administrators or owners.

This improvement (like the previous one) requires an account management system. Let’s summarize what this system needs to track:

● User data (login name, password, real name, email address...)

● Default user keyboard mapping

● List of active foreign images

○ Time remaining

● List of owned images

○ Filename and description (inherited from the common list)

○ Default image keyboard mapping

○ Screen resolution (customizable)

○ List of users allowed to do local access

○ List of other administrators

○ Status

■ Running/stopped

■ Current local access user

4.6 Load management policiesAnother issue discovered in FLOZ development is the necessity to

manage computational load measures when running more displays, a

113


need to be satisfied for both professional and experimental use. The measures this section will deal with are load average and memory usage.

The load average in POSIX systems is calculated as the exponentially damped moving average of the load number; the load number is the number of processes running, waiting for CPU or waiting for I/O at a certain time. In multiprocessor systems, load average should be divided by the number of CPUs to provide a meaningful value. Load average is usually calculated for the last minute, 5 minutes and 15 minutes, and is a very good way to determine CPU usage. Values lower than 1 denote almost idle processors, a value of 1 indicates medium loads, values greater than 23 mean a huge job.

Load average for a QEMU process depend on what OS it is running and what the OS is doing. A GUI session doing complex operations (like running a program with heavy computations) could increase dramatically QEMU load, while OS idle times and a console session should keep usage low. KQEMU acceleration reduces dynamic code translation overhead, thus lowering load demand.

Memory usage for QEMU is more easy to determine, as it uses little RAM for its dynamic translation, so memory usage is the memory it allocates for the guest OS. This amount can be set using the -m option in QEMU command line, which specifies how many megabytes should be reserved for the OS. Default value is 128 MB.

Good load average and memory management in FLOZ could be done, first of all, determining how many displays should be available. The best way to do it is calculating how much memory should be given to every image. Every OS has its needs, so a perimage memory setting should be implemented; then a average of the image settings should be calculated, and the total amount of memory should be divided by this average to have a good limit for available displays.

It should be also noted that QEMU Accelerator uses the special filesystem /dev/shm, which is mapped to physical memory. So /dev/shm

114


size should be adapted as needed, and a perimage Accelerator setting could be useful, too.

These steps will allow for optimal image management, while it should be difficult to optimize load average. The next level of optimization would be load balancing, i.e. distribution of FLOZ sessions among many servers. This should not be difficult to implement, using the policies of NX (section 2.4.3) or Linuxzoo (section 2.5.2); however, nonprofessional environments may have more problems in finding resources needed to buy a good number of servers.

Other improvements can be done, but those listed in this chapter should make FLOZ a really “complete” product, suitable for all needs. In addition to this, being a open source project, FLOZ will always be open to the contributions of other people; this is the very essence of FLOZ, the merge of work made by other people, and it will continue to be like this.

115

5 CONCLUSIONI

MAGNETO Ah, yes. Your continuing search for hope. You know this

plastic prison won’t hold me forever. The war is still coming,

Charles, and I intend to fight it... by any means necessary.

XAVIER And I will always be there... old friend.

“XMEN”

Questo lavoro di tesi ha analizzato le possibilità di realizzazione di un supporto di macchine virtuali dedicato alla sperimentazione di sistemi operativi diversi. Tale supporto è stato chiamato FLOZ, acronimo che contiene il termine “Zoo”, utilizzato dall’ideatore (Renzo Davoli) per dichiarare come OS anche diversi tra loro possano convivere nello stesso ambiente reale, in questo caso uno o più server distribuiti dotati di software per la creazione di macchine virtuali.

Si è trattato, principalmente, di un lavoro di assemblaggio: molti strumenti erano già disponibili, si trattava di farli cooperare insieme in modo da ridurre al minimo le operazioni (e quindi le competenze) richieste all’utente. Si trattava anche di scegliere gli strumenti più adatti da inserire, essendo spesso disponibili più soluzioni. La scelta, in realtà, è stata abbastanza semplice, in quanto sono stati seguiti tre criteri giudicati irrinunciabili:

● la massima portabilità dell’infrastruttura client di FLOZ, per slegarlo da qualsiasi vincolo hardware/software;

● il minor numero possibile di vincoli sui sistemi operativi utilizzabili, per dare all’utente le maggiori possibilità di sperimentazione e conoscenza;

● l’uso di software libero ed a sorgenti aperte, per avere massima libertà di sviluppo e lasciarla anche a chi vorrà

117


partecipare al progetto in futuro.

Dati questi criteri, in effetti, le scelte sono state abbastanza obbligate:

● Solo un sistema per macchine virtuali complete poteva togliere i vincoli sugli OS utilizzabili, e solo QEMU combina supporto a diverse architetture di processore, prestazioni e licenza GPL.

● Per l’infrastruttura di accesso remoto al sistema operativo, la scelta poteva essere fra VNC e NX. Il primo però, oltre ad essere già disponibile per QEMU, ha un’impostazione del protocollo del tutto slegata dalla sessione che si sta trasmettendo, una caratteristica che sembra meglio soddisfare la richiesta di assenza di vincoli sugli OS. Allo stesso modo, Java non ha praticamente rivali per le applicazioni clientbased, in quanto al tempo stesso portabile, diffuso e dalla struttura facilmente replicabile;

● Ampia scelta poteva essere fatta, probabilmente, per il server web e per le applicazioni di gestione serverside dello zoo; la scelta di Apache e PHP si è basata, oltre che sulla loro apertura, versatilità, espandibilità e diffusione, anche sull’esperienza personale dell’autore di questa tesi, abituato ad usarli ormai da anni.

Lo sviluppo dello zoo ha permesso di raggiungere pienamente i tre obiettivi sopracitati, a parte per quanto riguarda la licenza di QEMU Accelerator, che non è comunque un elemento indispensabile dello zoo, ma solo un utile ottimizzazione delle prestazioni.

Un punto di forza di FLOZ è, inoltre, l’utilizzo di un supporto di rete centrato sul client, progettato cioè in modo da demandare al software dell’utente ogni gestione del traffico entrante ed uscente dagli OS testati, e da sollevare da ogni possibile responsabilità il fornitore del servizio. Questo aspetto, estremamente innovativo rispetto a sistemi esistenti (vedi sezione 2.5) e reso possibile dalla versatilità di VDE, aiuta

118

Conclusioni

tra l’altro a ridurre di molto i requisiti di sicurezza di FLOZ.

Resta l’unico rammarico di non aver potuto, per motivi di tempo, sviluppare maggiormente alcuni aspetti di FLOZ, come il supporto di rete integrato nel client Java. Le possibilità future comunque non mancano, e la favorevole risposta avuta da molti utenti dal momento in cui il sistema è stato reso disponibile è certamente uno sprone a proseguire sulla strada iniziata.

119

BIBLIOGRAFIA

[AMD2006] “AMD I/O Virtualization Technology (IOMMU) Specification Rev 1.00”, Advanced Micro Devices Inc., 02 2006.

[App2006] “Universal Binary Programming Guidelines”, Apple Corporation, http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_intro/chapter_1_section_1.htm

l, 05 2006.

[Bar1973] Yonathan Bard, “An analytic model of cp67 – vm/370”, Proceedings of the workshop on virtual computer systems, pp. 170176, 1973.

[BDF+2003] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt e Andrew Warfield, “Xen and the art of virtualization”, SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles, pp. 164–177. ACMPress, New York, NY, USA, 2003. ISBN 1581137575.

[Bel2006] Fabrice Bellard, “QEMU Internals”, QEMU Web Site, http://qemu.org/qemu-tech.html, 05 2006.

[BPS+2004] Tim Bray, Jean Paoli, C.M. SperbergMcQueen, Eve Maler, François Yergeau, “Extensible Markup Language (XML) 1.0 (Third Edition)”, W3C Recommendation, http://www.w3.org/TR/2004/REC-xml-20040204, 02 2004.

[Cha2003] Merril R. Chapman, chapter 11 of “In Search of Stupidity: 20 years of hightech marketing disasters”, Apress 2003.

[Cho2002] P. Chown, “RFC 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)”, Internet Society, 06 2002

[Cre1981] R. J. Creasy, “The origin of the VM/370 timesharing

121

http://www.w3.org/TR/2004/REC-xml-20040204

http://qemu.org/qemu-tech.html

http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_intro/chapter_1_section_1.html




system”, IBM Journal of Research and Development, 25(5):483–490, 09 1981.

[Dav2004a] Renzo Davoli, Virtual Square Web Site, http://virtualsquare.org/, 2004.

[Dav2004b] Renzo Davoli, “VDE: Virtual Distributed Ethernet”, Technical Report UBLCS200412, Department of Computer Science, University of Bologna, 06 2004.

[Dav2005] Renzo Davoli, “Virtual Square”, Proceedings of the First International Conference on Open Source Systems, pp. 76–81, 07 2005.

[Dik2005] Jeff Dike, “Usermode Linux”, 12 2005.

[Gar2006] Ludovico Gardenghi, “UMView: ViewOS a livello user. Personalizzazione del file system a livello processo”, tesi di laurea in Informatica, Università di Bologna, 03 2006.

[Gas2006] Andrea Gasparini. “UMView: ViewOS a livello user. Nidificazione degli ambienti virtuali”, tesi di laurea in Ingegneria Elettronica, Università di Bologna, 03 2006.

[GosMcG1996] James Gosling, Henry McGilton, “The Java Language environment: a white paper”, Sun Microsystems Inc., http://java.sun.com/docs/white/langenv/, 05 1996.

[Hon2003] Jerry Honeycutt, “Microsoft Virtual PC 2004 Technical Overview”, Microsoft Corporation, 11 2003.

[Int2005] “Intel® Virtualization Technology specification for the IA32 Intel® Architecture”, Intel Corporation, 04 2005.

[Jav2004]“Java™ Remote Method Invocation Specification”, rev 1.10, Java SDK Standard Edition 1.5.0, Sun Microsystems, 2004.

[KMM1999] Eric Kohlbrenner, Dana Morris, Brett Morris, “The History of Virtual Machines”, Department of Computer Science Website, George Mason University, http://cs.gmu.edu/cne/itcore/virtualmachine/history.htm, 1999.

122

http://cs.gmu.edu/cne/itcore/virtualmachine/history.htm

http://java.sun.com/docs/white/langenv/

http://www.virtualsquare.org/vm.html

Conclusioni

[Mic2004] “Microsoft Windows Server 2003: Technical Overview of Terminal Services”, Microsoft Corporation, 2004 (agg. 01 2005).

[Mic2005] “Microsoft Virtual Server 2005 R2 Technical Overview”, Microsoft Corporation, 12 2005.

[Mic2006] “.NET Framework Conceptual Overview”, Microsoft Corporation, http://msdn2.microsoft.com/en-us/library/zw4w595w(VS.80).aspx, 2006.

[OMG2004] “Common Object Request Broker Architecture: Core Specification” Object Management Group, 03 2004.

[Pin2006] Gian Filippo Pinzari, “NoMachine NX Resources: Documentation”, NoMachine Web Site, http://www.nomachine.com/documentation.php, 2006.

[Pot2004] Herbert Pötzl, “LinuxVServer Technology”, Linux VServer Web Site, http://linuxvserver.org/Linux-VServer-Paper, 2004.

[Ric2005] Tristan Richardson, “The RFB Protocol version 3.8”, RealVNC Ltd., 07 2005.

[Rom1998] Pat Romano, “T.128 – Application Sharing”, ITUT Recommendation, 02 1998.

[Ros2004] Mendel Rosenblum, “The reincarnation of virtual machines”, ACM Queue, 2(5), 07 2004.

[RSWH1998] Tristan Richardson, Quentin StaffordFraser, Kenneth R. Wood, Andy Hopper, “Virtual Network Computing”, IEEE Internet Computing, Vol.2 No.1, pp. 3338, 0102 1998.

[SchWhi2000] Bruce Schneier, Doug Whiting, “A Performance Comparison of the Five AES Finalists”, Third AES Candidate Conference, 04 2000.

[SmiNai2005] J. E. Smith, Ravi Nair. “The architecture of virtual machines”, Computer, 38(5):32–38, 05 2005. ISSN 00189162.

123

http://linux-vserver.org/Linux-VServer-Paper

http://www.nomachine.com/documentation.php

http://msdn2.microsoft.com/en-us/library/zw4w595w(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/zw4w595w(VS.80).aspx


[WSG2002a] Andrew Whitaker, Marianne Shaw, Steven D. Gribble, “Denali: A scalable isolation kernel”, Proceedings of the Tenth ACM SIGOPS European Workshop, 09 2002.

[WSG2002b] Andrew Whitaker, Marianne Shaw e Steven D. Gribble, “Scale and performance in the denali isolation kernel”, SIGOPS Oper. Syst. Rev., 36(SI):195–209, 2002. ISSN 01635980.

[Vir2005] “Virtuozzo: An introduction to OS server virtualization and a new approach to server consolidation”, SWsoft White Paper, 2005.

124

RINGRAZIAMENTI

Grazie Signore, grazie,grazie Signore, grazie,grazie Signore, grazie,

graazieee!

– I QUELLILÌ

Di solito è questa la parte che l’autore della tesi scrive tra le prime, se non proprio per prima. È da tempo che penso a questa parte della tesi, perché ho sempre ritenuto molto importante il dire “grazie”, non solo come semplice atto di cortesia, ma come riconoscimento che quella persona esiste ed è importante per te, un riconoscimento che, credo, chiunque sia felice di ricevere.

Inoltre, mi ero clamorosamente dimenticato di scrivere i ringraziamenti nella mia tesi per la laurea triennale, il che può sembrare in contrasto con quanto ho detto poc’anzi; in realtà, da quando me ne sono accorto, ho cominciato a dirmi “va bene, recupererò con la specialistica”. Dunque qui entrano anche i ringraziamenti che non ho fatto allora, anche se essi sono comunque quasi un sottoinsieme di quelli relativi a questa tesi. Dopotutto, la tesi non è solo un impegno universitario, ma un momento importante della vita, uno spartiacque, soprattutto in questo caso, dunque entrano in gioco (e vanno ringraziati) persone ed ambiti che a prima vista poco o niente centrano con queste pagine.

L’ordine dei ringraziamenti è l’ordine col quale mi sono venuti in mente, che non necessariamente coincide con quello di importanza, né è del tutto indipendente da esso; ossia, è normale che si ricordino prima le persone più importanti, ma magari mentre scrivo mi viene in mente qualcuno che ha avuto un ruolo piccolo ma necessario, e lo metto prima di altri che hanno avuto ruoli più di primo piano. Così come può succedere che mi ricordi all’ultimo momento persone comunque molto importanti. Spero che nessuno si offenda, così come spero che non si

125


offendano i non citati; al 99% la loro omissione è frutto di semplice e banale dimenticanza, come i ringraziamenti nell’altra tesi.

Vàmonos.

● MAMI e PAPI, o Mamma Mattio e Papà Mattio. Non posso certo dire di avere avuto dei genitori che mi abbiano fatto mancare qualcosa, a cominciare dell’affetto. Non per questo mi hanno viziato più del dovuto, mi hanno invece insegnato che non tutto è dovuto nella vita, e a distinguere il necessario dal superfluo. Grazie anche per non avermi fatto pesare troppo l’aver sborsato le tasse universitarie per un anno di più, a causa del mio ritardo che non mi ha consentito di laurearmi a marzo.

● LUDOVICO, o Ludo, o <garden>, o Ludvig, mio cugino nonché punto di riferimento per quasi ogni cosa “tecnologica”. Ci sarebbero sempre un milione di motivi per ringraziarlo, riducendosi a ciò che riguarda questa tesi posso citare: i consigli sulla formattazione della tesi; quelli sul funzionamento del sito; l’aver messo a disposizione connessi.webminds.cs.unibo.it per le prime prove; molto testing; la sua conoscenza, tra l’altro, di VDE al cui codice ha collaborato; la pazienza con la quale risponde alle mie continue domande; l’avermi suggerito di retrocedere la versione di libgc1c2 per far tornare a funzionare Inkscape e quindi poter disegnare le figure di questa tesi; l’avermi fatto notare che FLOZ è anche l’oncia fluida (misura di capacità del sistema inglese); l’aver ricevuto nel 1991 il suo primo computer, spingendo poi me a farmelo regalare pochi mesi dopo ed ad entrare così in questo eterogeneo mondo; le sue domande su come si fa questo in CSS o come si rende valido quest’altro in XHTML 1.1, le uniche cose sulle quali ne so più di lui (solo perché lui in generale se ne interessa poco), che mi servono a ricordarmi che, soprattutto nell’informatica, c’è sempre da imparare. Diciamo che se oggi mi laureo, un buon 40% del merito va a lui.

● ‘BRIELE, o Canta, o Gabriele, o Cantagalli, insegnante (o controllore dei biglietti sul treno, fate voi), musicista e

126

Conclusioni

musicofilo, eterno attore sul palcoscenico della vita. Chiunque avrebbe bisogno di una persona che, semplicemente con il suo modo di essere, ti mette a tuo agio e ti fa mettere da parte un po’ qualsiasi problema. Il che ovviamente pone la questione: se tutti avessero chi li mette a proprio agio, chi metterebbe a proprio agio questi ultimi? Boh. Resta il fatto che se non avessi vicino una persona del genere, alla mia vita mancherebbe un po’ di sapore, come quando cuoci la pasta senza sale. Chi altro sarebbe capace, d’altronde, di filmare con una mano, guardare l’atlante con l’altra e guidare con le gambe? O chi mi avrebbe fatto scoprire le bellezze dell’Andalusia (dai, ‘Briele, che tra 3 settimane siamo lì)? O chi avrebbe inventato molti dei nomi strani che leggete in questo capitolo? Comunque, scusami se a Pentecoste non sono stato molto presente al coro, o sublime pargoletto.

● RENZO, o <reenzo>, o Davoli, o Renzo Davoli (certo non Davoli Renzo, anzi magari se legge questa parentesi me la fa cancellare o non mi fa laureare), che ben si potrebbe descrivere con l’epiteto assegnato da Omero ad Ulisse, polytropon (dal multiforme ingegno), per l’ampia cultura che possiede. Ispiratore, tra le altre, di un’idea (la sperimentazione di più sistemi operativi), che mi è piaciuta fin dall’inizio, ben prima che decidessi di farci una tesi sopra. Molto paziente coi miei ritardi, disponibile a ricevermi anche durante un esame, motivatore; il suo esempio mi sta facendo abbandonare sempre di più il software chiuso e proprietario. Siccome non voglio che la mia appaia come una captatio benevolentiae, visto che non lo è, la chiudo qui.

● DIO, chi me lo ha fatto conoscere, le persone che mi guidano nel cammino di fede, quelle con cui condivido quel cammino. Per uno come me la fede è un conforto non da poco, senza la quale probabilmente sarei una persona completamente diversa. Non credo che Lui si arrabbi se non è il primo della lista, visto che sa bene qual’è l’ordine “vero”. In particolare ringrazio quelle

127


persone che ho incontrato, rese belle dentro (e un po’ anche fuori) dalla fede, il cui esempio mi sprona ad andare avanti; don Fabio, che mi ha consigliato di accostarmi quotidianamente alla Messa, e in questo periodo è stato davvero importante; le persone che vanno a Messa ogni giorno a Santo Spirito, con le quali vivo la quotidianità della fede, fatta di piccole cose e gesti semplici.

● LUDOVICO (ancora) e ANDREA, o <garden> e <gaspa>, o [Gar2006, Gas2006], necessariamente insieme perché le loro tesi, presentate a marzo, sono state scritte in società in quanto entrambe incentrate su UMView/ViewOS, e quindi condividono gran parte del testo, in particolare la panoramica sulle macchine virtuali, che ha fornito una solida base per il capitolo 2 di questa tesi. Inoltre grazie a quelle tesi ho potuto dare una buona descrizione di UMView/ViewOS stesso in quel capitolo. Grazie dunque ad entrambi per aver concesso molto volentieri il loro materiale (tesi, bibliografia, articoli...), quanto lavoro che mi sono risparmiato! In effetti si meriterebbero parte del mio voto di laurea, ma non ne hanno bisogno...

● DANIELE, o <danielinux>, hacker sopraffino, capace di far passare connessioni Internet anche attraverso DNS, nonché prodigo nel documentare, qualità che non sempre vanno a braccetto. Autore di vde_cryptcab e disponibile ad aiutarmi nello scriverne la descrizione; grazie a lui il mio lavoro posttesi su FLOZ dovrebbe essere un po’ più facile, e questa è una bella cosa.

● Le persone che hanno ascoltato i miei pensieri durante questo periodo, in particolare DAVIDE (o <djgipos>, o Ughetto), compare di mille avventure, amico nel senso più pieno della parola, “maestro di vita” (no, non è il “mago” Do Nascimiento) con le sue sensations. Finalmente siamo tornati a fare i disgiòcar69 come una volta, a star dietro al tavolino e avere per qualche ora il controllo della situazione. E presto torneremo anche a far gli

69 ‘A vói fèr ‘e disgiòcar’ Andrea Mingardi. Saranno giusti accenti e apostrofi?

128

Conclusioni

scemi su un palcoscenico. Poi ci sono gli altri, come LUCA (o TuKa) e MICHELE (o Demichelis), coi quali ho fatto chiacchierate più o meno fugaci via Internet, comunque importanti anche per staccare la spina ogni tanto.

● BET (o Massimo) e FABIO (o Divinatore) che mi hanno fatto scoprire la mitica Sfida a Prato Fiorito (Minesweeper Flags) di MSN Messenger, uno dei pochi svaghi concessi durante la stesura della tesi, facendomi installare Windows XP (no, non piratato) in QEMU per poterla usare senza riavviare o usare altri computer, per scoprire che tutto sommato funziona anche bene, e facendomi venir voglia, quando tutto questo sarà finito, di scriverne un clone. Poi magari finisce che non lo faccio, ma insomma...

● Quelli del gruppo a Santo Spirito, grazie ai quali mi sento, lì, davvero come a casa mia. In particolare GINEX (o Ginex101, o Isacco, o Fabio) e GELINO (o Matteo), buone persone, che se potessero darti tre mani lo farebbero, e che sono comunque di grandissimo aiuto anche dandone una sola; LELLINO (o Gabriele), infaticabile organista e direttore di coro, uomo di tutta concretezza; i pargoletti della squadra (e non solo), SAVÉRIO, GERARDO, DINO, GALLO, SCÀLTRO, BAXUELL, IPPO, GIOACCHINO, BÒ, TOSCO, PALETTA, (spero di non essermene scordati) compagni di mille gozzoviglie; le soavi pargolette, che non nomino singolarmente per evitare di farne arrabbiare qualcuna nel caso me ne dimenticassi – fate conto che vi abbia nominate tutte.

● I frequentatori dei canali IRC #acheronte, #caristudenti, #osd su Freenode, fonte di aiuto per eventuali dubbi; segnalo in particolare <garden>, <gda>, <mana>, <luindir>, <pa>, <tomasino>, <gaspa>, <danielinux> e quelli che, chiedendomi il perché il mio nick fosse <MG55>, mi hanno spinto a produrre una ponderosa pagina descrittiva70 per spiegarlo, e poi mi hanno aiutato ad ampliare la pagina stessa.

70 http://mg55.homeip.net/55

129

http://mg55.homeip.net/55


● I miei pargoletti del gruppo GVSS, di cui sono educatore insieme a BANDO (o Matteo) ed ERIKA: SIMO, ANDRO, ZACK, CARLO, GIARGO, SUSY, AGNESE, GIULIA, GIULIA, MISCIO, LETY, CRIS e chi compare ogni tanto. Perché nonostante spesso non mi senta molto adeguato per questo compito, mi piace camminare insieme a loro, stando per un po’ nel loro mondo di adolescenti che è stato anche il mio mondo, neanche tanto tempo fa. E scusatemi se ultimamente sono stato poco presente, sia fisicamente che con la testa.

● Gli educatori GVSS della diocesi di Imola, con i quali ho passato dei bei momenti a preparare e poi a condurre ritiri, la sera al bar dopo le preparazioni stesse, la notte nell’atrio di Tossignano a strafogarsi di arachidi ed altro, oppure a fare scherzi ai GVSS, oppure a farceli tra noi (vero Bando?). Perché da loro ho avuto la conferma che qualsiasi progetto educativo parte dal voler bene ai ragazzi, nonostante tutto.

● I pusher della mia dose di humour quotidiano: GARFIELD71 (ovvero se casca il mondo mi sposto), ERIADAN72 (la personalizzazione dei pensieri di tutti e dei luoghi comuni), USER FRIENDLY73 (roba per noialtri informatici malati), che mi aiutano a iniziare la giornata col sorriso. Da aggiungere anche DAVIDE BIANCHI con le sue Storie dalla Sala Macchine74 (ma grazie anche per avermi introdotto ai misteri di .htaccess), che da un lato mi inquietano al pensiero che esistano certi utenti di computer (non tanto per l’incompetenza, tutti siam stati utonti nella vita, ma per la capacità di combinare disastri e di fare una cosa se ti hanno appena detto di non farla), dall’altro mi divertono assai tutti i lunedì (magari mi divertirò meno se/quando cose del genere capiteranno a me). Ultimi ma primi, i PEANUTS, capolavoro dell’era contemporanea, opera di poeta, come disse Umberto Eco; finalmente sto realizzando il sogno di avere la collezione

71 http://garfield.com/comics/comics_todays.html72 http://www.eriadan.com/ e http://museoeriadan.shockdom.com/73 http://userfriendly.org/static/74 http://soft-land.org/storie

130

http://soft-land.org/storie

http://userfriendly.org/static/

http://museoeriadan.shockdom.com/

http://www.eriadan.com/

http://garfield.com/comics/comics_todays.html

Conclusioni

completa (grazie alla FANTAGRAPHICS BOOKS che lo ha reso possibile), ci vorrà ancora una decina d’anni, ma siamo sulla buona strada ;)

● I compagni di avventure di 6 anni di università, in particolare quelli con i quali ho presentato progetti vari: LUDVIG, ANDREA P., <rnz>, RAFFAELE, TUKA, GIOVANNI, ANDREA V., MARCO, MAURIZIO, MICHELE. Se faccio un rapido flashback, mi viene in mente che ne abbiamo passate proprio di tutti i colori, ma in un modo o nell’altro ce la siamo sempre cavata.

● FABIO VITALI, mio relatore per la laurea triennale, perché comunque se oggi sono qui è anche perché allora ero con lui a far la tesi; perché facendo l’esame di Tecnologie Web (o Laboratorio Tecnologie Web, come allora si chiamava) sono diventato un integralista della validazione delle pagine web e mi sono addentrato nei meandri di PHP, cose che per questa tesi mi sono servite non poco (OK, magari la prima era trascurabile, ma come ho detto sono integralista...); perché ho conosciuto grazie a lui Donald Norman e la psicologia cognitiva, che mi ha fatto rivedere in positivo il mio giudizio sulla psicologia in generale e mi ha dato un nuovo modo di ragionare sulle cose che ci circondano (ad esempio, un maniglione antipanico sarebbe più adatto allo scopo se fosse più largo nella parte lontana dalla cerniera, per dare un “invito” sul punto dove è meglio spingere), cosa che nessun altro esame mi ha dato, in questi anni; perché grazie a quella passione per i siti Web più volte mi è successo di scrivere, magari in IRC, robe come “Sì, l’esame è andato bene”, salvo comunque accorgermene quasi sempre prima di premere Invio (ora, grazie a Tidy75, questo non succede più).

● La SUN, che rilasciando il sorgente di StarOffice ha permesso la nascita di una suite alternativa a Microsoft Office, open source, completa, multipiattaforma, con un formato dati aperto e ora

75 http://tidy.sourceforge.net/

131

http://tidy.sourceforge.net/


pure standard ISO, e a me di poter scrivere la tesi potendo rinunciare ad Office e al tempo stesso senza dover imparare TEX (che comunque dovrò imparare prima o poi, se non altro per avere le legature nelle “fi”), cosa che, data la mia velocità, mi avrebbe fatto laureare a dicembre 2008 (ovviamente sto esagerando). Grazie anche a chi ha scritto il dizionario della versione italiana, che segnala “Windows” come errore e “Linux” no. Siete mitici.

● La NETSCAPE, che facendo la stessa cosa con il suo browser ha gettato il seme per quel virus benigno che è Firefox, 100 milioni di download in un anno, probabilmente 200 entro i 2 anni, che mi ha fatto vincere un buono sconto, che durante la scrittura di questa tesi viaggiava costantemente sul mio computer con le sue tre belle file di tab, che ha spinto creativi di tutto il mondo a creare spot esilaranti per promuoverlo76, che ha messo un po’ di paura a Microsoft dopo tanto tempo e le ha fatto scrivere un browser che rispetto alla versione precedente sembra un altro programma.

● Quelli con cui ho passato tante serate a giocare a DUNGEONS & DRAGONS, e che ho temporaneamente abbandonato causa questa tesi: PAOLO, GIPOS, ZELLO, GIOVA, RENNA, BET, FABIUS, MUGEL, POLI , non tutti nello stesso momento. Mi diverto molto a stare in un mondo parallelo per qualche ora alla settimana, e mi piacerebbe interpretare ancora di più, calarmi meglio nel ruolo. Comunque tornerò, la mia raffica di colpi è sempre pronta. E ora ho pure i dadi metallici...

● IMDB77 (INTERNET MOVIE DATABASE) per le citazioni da Matrix e XMen. Tra i film che mi sono più piaciuti, credo che Matrix sia quello che più richiama l’idea di FLOZ, e più in generale dei progetti software citati nella tesi78. Pensi di stare usando un

76 come http://firefoxflicks.com/flick/?sort=rtg&id=1954277 http://imdb.com/78 Penso a ViewOS: credi di avere il controllo di tutto, e non è vero! Proprio come in

Matrix. Ma perché penso queste cose alle 3:15 e non mi vado invece a letto?

132

http://imdb.com/

http://firefoxflicks.com/flick/?sort=rtg&id=19542

Conclusioni

computer, ma in realtà stai usando un computer finto dentro a un computer vero. La citazione da XMen ricorda (e mi ricorda) che il lavoro su FLOZ è tutt’altro che finito con questa tesi, ma almeno avrò scadenze meno improrogabili. Mi piacerebbe mettere citazioni a caso provenienti da altri miei film/libri preferiti, ma evitiamo di andar troppo fuori tema.

● RICK CHAPMAN, per avermi fatto conoscere nel suo libro [Cha2003], in modo molto divertente, il mondo dell’industria IT visto da “quelli del marketing”. Un’esperienza molto interessante, che raccomando a tutti: l’edizione italiana del libro di intitola Alla ricerca della stupidità: 20 anni di disastri hitech, ed è edita da Mondadori Informatica. C’è pure il sito Internet79.

Come detto, le eventuali assenze sono quasi sicuramente frutto di dimenticanza, e non di una voluta omissione. A questi, ed agli altri, un grazie grande grande.

Non chiedetemi cosa succederà adesso. Il massimo che posso dirvi è che porterò a termine questo progetto, e che tornerò in Andalusia in agosto. Tutto il resto è nebbia.

Statemi bene.

79 http://www.insearchofstupidity.com/

133

http://www.insearchofstupidity.com/

Zoo di sistemi operativi: supporto di macchine virtuali...

Documents

Transcript of Zoo di sistemi operativi: supporto di macchine virtuali...