USER MODE LINUX

… Chi era costui? ...

Università degli Studi di Bologna

Dipartimento di Scienze dell’Informazione

Seminario per il Corso di Laboratorio di Sistemi Operativi

Micaela Spigarolo

INTRODUZIONE

INSTALLAZIONE E LOGGING IN

NETWORKING

SOMMARIO

Cos’è UML

A cosa serve

Installare UML

Come ottenere UML

Boot della macchina virtuale

Logging in - logging out

HOSTFS

Possibilità di configurazione della rete - modalità COW

Ethertap, UML switch

VDE

UML AVANZATO

Emulazione della memoria virtuale

Emulazione di trap e interrupt

Context switch

USER MODE LINUX

UML

kernel

fs

PATCH

Kernel

2.4.19

User Mode Linux

Http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.HTML

UML è una patch del kernel Linux che permette a un eseguibile binario di essere costruito ed eseguito nello spazio utente di una macchina Linux reale che funge da host

CONSEGUENZA:

INTRODUZIONE

Tutto ciò che avviene sulla macchina virtuale non influenza affatto l’integrità della macchina host reale!

Hardware - CPU, disks, networks, terminals, ...

Generic kernel

Architecture layer

drivers

drivers

ls

ps

Mozilla

user-mode arch

generic kernel

ls

ps

Mozilla

Livello dei processi

UML è un kernel debitamente modificato con apposite patch, chiamato uml-linux, e reso eseguibile al pari di un comune programma applicativo

CARATTERISTICHE

Il codice dipendente dall’architettura che comprende UML implementa tutti i supporti hardware di basso livello in termini di system call

UML porta Linux su Linux: tratta Linux come una piattaforma sulla quale possa essere portato il kernel (i.e. Intel o Alpha). Non si tratta però di un nuovo pezzo hardware, ma piuttosto è una piattaforma software definita dall’intefaccia delle system call di Linux

Il codice userspace funziona in modo nativo sul processore senza alcuna sorta di emulazione di istruzioni

Processi attivi sotto UML non hanno accesso alle risorse host che non siano state esplicitamente fornite alla macchina virtuale

VIRTUAL NETWORK E

X SESSION

REALIZZAZIONE

Il kernel Linux (portabile) si divide in due parti:

Una platform independent, che è la parte grossa del kernel ed è la stessa per ogni piattaforma

L’altra plataform dependent,

Architectur Layer

che è una parte molto più piccola

Implementa tutte le funzionalità di basso livello che richiedono coinvolgimento diretto con l’hardware. Comprende cose del tipo:

Entrare e usicre dalla modalità kernel

context switch dei processi

modifica di protezione della memoria

creazione e terminazione dei thread

CREARE MACCHINE VIRTUALI

MEMORIA RAM

Processore

Memoria: disco e RAM

Periferiche di I/O

MACCHINA DI VONNEUMANN

BUS

DISCO

PROCESSORE

Condiviso

Ritagliata dalla RAM fisica (in genere 30 MB, ma volendo si puo’ cambiare) e dedicata in modo esclusivo alla vm del kernel residente

File presenti sull’hard disk della macchina reale

USER MODE LINUX

File System host

File

Memoria centrale del sistema host

File System uml

Scheda di rete

Dom. di collisione virtuale

Scheda di rete del sistema host

Dom. di collisione del sistema host

ROOT FILESYSTEM

VM

Per indicare una macchina virtuale

HOST

Per indicare la macchina reale che ospita la vm nella sua ram

La memoria non volatile (unità disco) di una vm è emulata per mezzo di un file risiedente nella memoria fisica della macchina host

L’analogia con il mondo reale consiste nel poter decidere di:

“acquistare” un PC con SO preinstallato

“comprare” un disco vuoto per installare la nostra distribuzione preferita

Uso per UML un file gia’ pronto e confenzionato da altri

Utilizzo un file vuoto da riempire simulando un’installazione

Naturalmente, la dimensione del file sul filesystem corrisponde allo spazio che abbiamo a disposizione all’interno della vm

SYSTEM CALL

INTERCEPTION

Implementare UML significa scrivere un nuovo architecture layer che implementi tutte queste funzinalità in termini di system call

Poiché UML fa funzionarelo stesso binario del kernel host e tale binario esegue le system call nello stesso modo dell’host, UML deve essere capace di:

Intercettare le system call

Prevenire la loro esecuzione nel kernel host

eseguirle nel proprio contesto

Questo è realizzato tramite ptrace(), Meccanismo di Tracing delle System call. Esso permette a un processo di intercettare e modificare la system call di un altro.

SYSTEM CALL

INTERCEPTION

UML utilizza thread speciali (Tracing Thread) il cui unico job è quello di tenere traccia di quasi tutti gli altri thread.

Quando un processo UML (in user space) fa una system call, il tracing thread:

La intercetta e la legge dal registro dei processi

La modifica in modo da renderla una chiamata a getpid() (rendendola effettivamente nulla)

Salva i registri del processo nella struttura thread e impone qualche stato precedentemente salvato

(continua)

Questo nuovo stato fa in modo che il processo dia inizio all’esecuzione dell’handler di system call che:

Legge la system call e gli argomenti dal proprio registro di salvataggio

Invoca il codice della system call

USER MODE E

KERNEL MODE

Quando il thread ha terminato di eseguire la sytem call, è pronto a restituire un valore indietro al processo.

Il processo memorizza tale valore nei prorpi registri precedentemente salvati e chiede al thread di tracciamento di essere riportato in user mode (tramite signal SIGUSR1).

Il tracing thread, cioè:

Assegna il valore di ritorno della system call al registro appropriato

Ripristina i registri salvati

Ripristina il meccanismo di tracciamento delle system call

A questo punto l’intercettazione delle system call è stata sospesa, cosa che permette al thread stesso di eseguire la system call nel kernel host. Tutto ciò realizza una forma di modalità kernel PRIVILEGIATA.

PECULIARITA

La macchina virtuale UML può avere più risorse hardware e software virtuali rispetto a quelle possedute dalla macchina reale

La memoria del disco per la macchina virtuale è interamente contenuta in un unico file risiedente nella macchina fisica

E’ possibile assegnare alla macchina virtuale solo l’accesso all’hardware che si vuole concedere. Con accesso adeguatamente limitato nulla che venga fatto sulla macchina virtuale potrà modificare o danneggiare il proprio computer reale né il suo software

A COSA SERVE UML

VIRTUAL HOSTING

EDUCATION

EXPERIMENTAL DEVELOPMENT

VIRTUAL NETWORKING

KERNEL DEVELOPMENT AND DEBUGGING

UML può far funzionare tutto ciò che la macchina host può far funzionare

La macchina virtuale UML può essere utilizzata come box di testing del kernel

UML permette di fornire ogni studente di macchine dedicate sicure e in grado di effettuare sperimentazioni reali.

La macchina virtuale UML può essere configurata in modi in cui la macchina reale non può (i.e. più memoria, più dispositivi, ecc.)

Ogni macchina virtuale UML è navigabile da parte di ogni altra, dell’host e di altre macchine reali.

INSTALLARE UML

ESISTONO DUE POSSIBILITA’:

Scaricare e applicare la patch al proprio kernel.

Scaricare pacchetti precompilati in formato .deb o .rpm

In tal caso occorre scaricare e installare anche le utility

L’installazione dei moduli del kernel avviene automaticamente

DI COSA HO BISOGNO:

relativa alla versione del kernel della macchina host

Patch

Utility

+

Pacchetto precompilato

File System

+

+

1

2

RICOMPILARE IL KERNEL

UML

kernel

fs

PATCH

Kernel

2.4.19

User Mode Linux

Scaricare l’ultima versione patch UML dal sito del progetto. Nel nostro es., abbiamo scaricato il file uml-patch-2.4.19.bz2

Scaricare il kernel correlato

Creare una directory e scompattare il kernel

pippo# cd /usr/src/uml

pippo# tar -xzvf linux_2.4.19.tar.bz2

Compilare il kernel UML è esattamente uguale a ricompilare qualsiasi altro kernel Linux:

RICOMPILARE IL KERNEL

Applicare la patch

pippo# cd /usr/src/uml/linux

pippo# cat uml-patch-2.4.19.bz2 | bunzip2 - | patch -p1

(continua)

Utilizzare il proprio config preferito.

make config: classico ma molto scomodo. Possiede interfaccia a linea di comando

make menu-config: ad interfacci agrafica

make xconfig: per ambiente Xwindows

Si tratta di un apposito programma che crea un file di configurazione nelquale sono inserite le opzioni per la ricompilazione. Ne esistono di tre tipi:

pippo# make xconfig ARCH=um

pippo# make linux ARCH=um

APPLICARE I MODULI

I moduli del kernel vengono costruiti nello stesso modo del kernel nativo, con la sola eccezione dell’utilizzo di ARCH=um, che è sempre necessario per UML

pippo# make modules ARCH=um

(continua)

Se UML è stato installato tramite pacchetti precompilati di tipo .deb o .rpm, le utility sono comprese nel pacchetto stesso e vengono automaticamente installate. Se invece si è proceduto per ricompilazione del kernel, occorre porre attenzione a reperire le utility cheinteressano e ad installarle.

uml_mconsole

uml_moo

uml_net

uml_switch

COME OTTENERE UML

UML è completamente configurabile da linea di comando

DI COSA UML HA BISOGNO:

Un eseguibile denominato linux e creato all’atto dell’installazione del pacchetto precompilato (formato .deb o .rtf) o dell’applicazione della patch UML al kernel Linux della macchina host

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

Un file system (file residente sulla macchina host) sul quale fare boot e che tiene memoria di tutto ciò che è stato fatto nella macchina virtuale (creazione di file e directory, installazione di nuovo software, ecc.) .

COME OTTENERE UML

Il root filesystem è generalmente contenuto in un file che semplicemente contiene un immagine ext2 di filsystem.

E’ possibile usare dd per cerare un proprio filesystem ext2 oppure uno ampio quanto le proprie esigenze richiedano e copiarci dentro il root filesystem di UML.

pippo# dd if=/dev/zero/ of=/uml/uml_rootFS bs=1M count=500 seek=1

pippo# /sbin/mke2fs /uml/uml_rootFS

Supponendo che il file contenente il root filesystem UML sia denominato debian_root, è possibile montare i due filesystem e copiare il contenuto dell’uno (Debian, più piccolo) nell’altro (creato da noi)

pippo# mount -o loop /uml/uml_rootFS /uml/mnt/uml_rootFS

pippo# mount -o loop /uml/debian_root /uml/mnt/debian

pippo# cp -fra /uml/mnt/debian/* /uml/mnt/uml_rootFS

BOOT DELLA MV-UML

pippo# /usr/lib/linux ubd0 = path/root_fs

Eseguibile che fa il boot della MV

File che funge da filesystem per la macchina virtuale

Equivale ad hda per la machina fisica

Non occorre essere utente di root per fare tutto ciò!

ubd = UML Boot Device

LOGGING IN

Al boot la macchina virtuale UML si mostra come una qualsiasi richiesta di login di Linux

La particolare versione di Linux (Red Hat, Deban, Mandrake, ecc.) è determinata dal root_fs scaricato e montato. Quest’ultimo può anche essere anche realizzato ad hoc, trattandosi dell’immagine di un filesystem

Generalmente vengono aperte due finestre di console ed è possibile collegarsi ad esse come root (con password provvisoria “root”) o come user (con password provvisoria “user”)

~/linux/2.3.26/um 999: linux ubd0=../distros/slackware_7.0/root_fs_slackware_7_0 \

ubd1=../distros/suse_6.3/root_fs_suse mem=128M ubd2=swap ubd3=../kernel \

umn=192.168.0.100 ubd4=/dev/hdc ubd5=../lmbench

signal thread pid = 2438

idle thread pid = 2439

Linux version 2.3.99-pre8-1um (jdike@ccure.karaya.com) (gcc version \

egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #30 Sat May 20 13:27:43 \

EST 2000

On node 0 totalpages: 32768

zone(0): 256 pages.

zone(1): 32512 pages.

zone(2): 0 pages.

Calibrating delay loop... 444.33 BogoMIPS

Memory: 128744k available

Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)

Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)

Page-cache hash table entries: 32768 (order: 5, 131072 bytes)

kmem_create: Poisoning requested, but con given - bdev_cache

Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)

kmem_create: Poisoning requested, but con given - inode_cache

VFS: Diskquotas version dquot_6.4.0 initialized

POSIX conformance testing by UNIFIX

Linux NET4.0 for Linux 2.3

Based upon Swansea University Computer Society NET3.039

kmem_create: Poisoning requested, but con given - skbuff_head_cache

A SIMPLE LOGIN SECTION

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP

IP: routing cache hash table of 1024 buckets, 8Kbytes

TCP: Hash tables configured (established 8192 bind 8192)

Starting kswapd v1.6

pty: 256 Unix98 ptys configured

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

loop: registered device at major 7

loop: enabling 8 loop devices

Initializing stdio console driver

Initializing software serial port version 0

serial line 0 assigned pty /dev/ptyp2

ssl receive thread is pid 2444

devfs: v0.96 (20000430) Richard Gooch (rgooch@atnf.csiro.au)

devfs: devfs_debug: 0x0

devfs: boot_options: 0x0

VFS: Mounted root (ext2 filesystem) readonly.

Mounted devfs on /dev

INIT: version 2.76 booting

/etc/rc.d/rc.S: Testing filesystem status: Read-only file system

Parallelizing fsck version 1.15 (18-Jul-1999)

/dev/ubd/0: clean, 29389/131072 files, 389992/524288 blocks

Remounting root device with read-write enabled.

/dev/ubd/0 on / type ext2 (rw)

none on /dev/pts type devpts (rw,gid=5,mode=620)

none on /proc type proc (rw)

Updating module dependencies for Linux 2.3.99-pre8-1um:

can't locate module slip

can't locate module ppp

can't locate module bsd_comp

Starting PCMCIA services: module directory /lib/modules/2.3.99-pre8-1um/pcmcia \

not found.

INIT: Entering runlevel: 3

Going multiuser...

Configuring umn as 192.168.0.253...

Activating IPv4 packet forwarding...

Starting /sbin/rpc.portmap...

Mounting remote file systems...

Starting daemons: syslogd klogd inetd lpd mountd nfsd

Starting sendmail daemon (/usr/sbin/sendmail -bd -q15m)...

451 /etc/sendmail.cf: line 0: cannot open: No such file or directory

Loading the iBCS module...

insmod: iBCS: no module by that name found

/var/lib/apache/sbin/apachectl start: httpd started

Starting Samba...

Setting time zone...done

Welcome to Linux 2.3.99-pre8-1um.

darkstar login: root

Password:

Linux 2.3.99-pre8-1um.

Last login: Sat May 20 14:10:56 -0500 2000 on ttys/2.

You have mail.

darkstar:~#

darkstar:~# ps uax

Unknown HZ value! (20) Assume 100.

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

root 1 0.0 0.1 344 184 ? S 14:23 0:00 init

root 2 0.0 0.0 0 0 ? SW 14:23 0:00 [kswapd]

root 3 0.0 0.0 0 0 ? SW 14:23 0:00 [kflushd]

root 4 0.0 0.0 0 0 ? SW 14:23 0:00 [kupdate]

bin 61 0.0 0.3 1076 388 ? S 14:23 0:00 /sbin/rpc.portmap

root 65 0.0 0.4 1360 620 ? S 14:23 0:00 /usr/sbin/syslogd

root 68 0.0 0.3 1096 496 ? S 14:23 0:00 /usr/sbin/klogd -

root 70 0.0 0.4 1332 540 ? S 14:23 0:00 /usr/sbin/inetd

root 72 0.0 0.4 1380 556 ? S 14:23 0:00 /usr/sbin/lpd

root 75 0.0 0.5 1540 704 ? S 14:23 0:00 /usr/sbin/rpc.mou

root 77 0.0 0.5 1556 704 ? S 14:23 0:00 /usr/sbin/rpc.nfs

root 79 0.0 0.3 1172 500 ? S 14:23 0:00 /usr/sbin/crond -

daemon 81 0.0 0.4 1180 580 ? S 14:23 0:00 /usr/sbin/atd -b

root 94 0.0 0.9 2156 1196 ? S 14:23 0:00 /var/lib/apache/s

nobody 95 0.0 0.9 2168 1188 ? S 14:23 0:00 /var/lib/apache/s

nobody 96 0.0 0.9 2168 1188 ? S 14:23 0:00 /var/lib/apache/s

nobody 99 0.0 0.9 2168 1188 ? S 14:23 0:00 /var/lib/apache/s

nobody 100 0.0 0.9 2168 1188 ? S 14:23 0:00 /var/lib/apache/s

nobody 102 0.0 0.9 2168 1188 ? S 14:23 0:00 /var/lib/apache/s

root 104 0.0 0.7 1732 1000 ttys/0 S 14:23 0:00 -bash

root 105 0.0 0.3 1048 432 ttys/1 S 14:23 0:00 /sbin/agetty 3840

root 106 0.0 0.3 1048 432 ttys/2 S 14:23 0:00 /sbin/agetty 3840

root 107 0.0 0.3 1048 432 ttys/3 S 14:23 0:00 /sbin/agetty 3840

root 119 0.0 0.5 2360 732 ttys/0 R 14:23 0:00 ps uax

darkstar:~# halt

INIT: Switching to runlevel: 0

INIT: Sending processes the TERM signal

Broadcast message from root (ttys/0) Sat May 20 14:27:06 2000...

The system is going down for system halt NOW !!

darkstar:~# INIT: Sending processes the KILL signal

Running shutdown script /etc/rc.d/rc.0:

Unmounting remote filesystems.

Turning off swap.

Unmounting local file systems.

Remounting root filesystem read-only.

Power down.

~/linux/2.3.26/um 1000:

LOGGING OUT

Il logout avviene con i comandi tipici per scollegarsi da un sistema Linux per PC (shutdown, halt, ecc.)

HOSTFS

vm-pippo# mount none /mnt/home -t hostfs -o /home/name

Path della porzione di filesystem dell’host che si vuole rendere accessibile dalla macchina virtuale

hostfs permette alla macchina virtuale di accedere ai file contenuti nel filesystem dell’host!

UML possiede un filesystem virtuale che fornisce acceso diretto al filesystem della macchina host. Esso è ottenuto implementando l’interfaccia virtual filesystem in termini di chiamate di accesso a file seull’host. La maggior parte delle operazioni VFS vengono tradotte direttamente nelle equivalenti chiamate libc sull’host

NETWORKING

La macchina virtuale UML può voler comunicare con la macchina host o con altre macchine fisiche connesse con la macchina host, o viceversa

Più macchine UML virtuali possono avere la necessità di comunicare tra di loro

Su di uno stesso host è possibile far partire più macchine vistuali UML

COPY ON WRITE FILE

Non è possibile un accesso concorrente di più vm al medesimo root filesystem senza correre il rischio di renderlo inconsistente

Soluzione: uso di file di tipo sparse gestititi con il meccanismo di Copy-On-Write (da cui il nome di cow-file o cow-disk)

un backing file con contenuti fissi, read only e condiviso da tuttte le vm

più file Copy-On-Write di tipo sparse, ciascuno per ogni vm e contenente le sole variazioni apportate dalla vm al file condiviso (il backing file)

Idea: Il cow-file contiene le sole modifiche apportate dalla singole vm. Ogni vm scrive sul proprio cow-file e legge dal filesystem condiviso o dal proprio cow-file in cache, se i dati richiesti sono presenti e validi

La tecnica consiste nell’avere:

INTERFACCE DI RETE

ETHERTAP

MULTICAST

SWITCH DAEMON

SLIP

TUN/TAP

Per accedere al networking dell’host, se si possiede una macchina 2.2

Se si vuole accedere al networking dell’host e si possiede una macchina 2.4

Se si desidera una rete puramente virtuale e non si vuole settare altro se non UML

Se si vuole una rete puramente virtuale e non ci si preoccupa delle influenze del demone sulle prestazioni

Protocollo alternativo a TUN/TAP e ethertap

ETHERTAP

pippo# /usr/lib/linux ubd0=cow_file,root_fs

eth0 = ethertap, tap0, fe:fd:0:0:0:1, 10.1.1.1

<device>

<ethernet adderess>

<tap IP address>

HOST

UML

10.1.1.1

10.1.1.2

eth0

eth0

CONFIGURAZIONE

L’indirizzo IP assegnato all’estremità host del dispositivo tap deve essere diverso dall’indirizzo IP assegnato al dispositivo eth dal lato UML!

vm-pippo# ifconfig eth0 10.1.1.2 up

Con questo comando parte una macchina UML virtuale con scheda di rete eth0 configurata per quanto riguarda il lato host. Essa deve essere configurata anche per il lato UML del dispositivo. Eventualmente si può voler settare il route verso il resto del mondo.

FORMA GENERALE

eth <n> = <transport> , <transport args>

CONFIGURAZIONE DA LINEA DI COMANDO :

ifconfig eth <n> <IP_address> up

route add default gw <host_IP>

CONFIGURAZIONE DAL LATO UML :

SWITCH DEAMON

eth <n> = daemon,<ethernet address> , <socket type> , <control socket> , <data socket>

FORMA GENERALE:

Far funzionare il demone senza specificare alcun argomento, fa in modo semplicemente che il driver eth0 si connetta con il demone corrente!

Il demone di switch fornisce un meccanismo per creare una rete totalmente virtuale senza connessioni con la rete dell’host. Per prima cosa occorre far partire il demone:

pippo# uml_switch

ESEMPIO

HOST

UML 1

10.1.1.1

10.1.1.2

eth0

eth0

10.1.2.1

eth1

pippo# uml_switch

pippo# /usr/lib/linux ubd0 = path/root_fs

eth0 = ethertap, tap0, fe:fd:0:0:0:1, 10.1.1.1

eth1 = daemon

UML 2

10.1.2.2

eth0

SCRIPT

#!/bin/sh

FS_ADDRESS=‘/my_dir/pippo/UML_root’

/usr/lib/linux ubd0 = $FS_ADDRESS/1_root_fs.ext2

ubd1=$FS_ADDRESS/2_root_fs.ext2

eth0 = ethertap, tap0, , 10.1.1.1

eth1 = daemon

Il coltellino svizzero per l’emulazione di reti: è in grado di creare reti virtuali distribuite Ethernet-compliant.

--> Può essere usato come:

rete virtuale (in termini generali)

tecnologia di supporto alla mobilità, strumento per il testing delle reti, layer per l’implementazione di tecnologie per il rispetto della privacy e molto ancora

Il collegamento con il resto del mondo avviene per mezzo di un’interfaccia tuntap o attraverso il supporto slirp.

VDE

Virtual Distributed Ethernet

Funziona come processo a livello utente ed è trasparente ai protocolli di rete: ogni protocollo in grado di funzionare su una Ethernet può essere supportato da VDE.

VDE ha la stessa struttura di una moderna rete Ethernet. I componenti

chiave sono vde switch e vde cable

Vde_switch: è la controparte virtuale di uno switch reale (hub)

vde_cable: è la controparte virtuale dei cross-cable che permettono di connettere due switch

vde_plug: programma progettato per essere connesso a un vde_switch: converte tutto il traffico in uno strem di connessione standard

Tool di connessione, in grado di congiungere in maniera bidirezionale gli stream appartenenti ai due vde_plug

VDE

Vde switch si comporta come uno switch reale: è un fast-bridge in grado di gestire l’associazione dinamica tra indirizzi hardware (MAC) e porte. Ogni componente vde cable è costituita da tre componenti software:

(continua)

VDE

(continua)

È possibile creare vde_cable che connettono vde_switch locali o

in remoto.

Tale connessione avverrà per mezzo di una doppia pipe tra le unità

vde_plug.

Ogni servizio in esecuzione in remoto farà riferimento a un vde_switch remoto per mezzo di strumenti standard quali, per esempio, rsh e ssh.

Un vde_cable con ssh si comporta come un tunnel criptato general-purpose.

HTTP://www.cs.unibo.it/techreports/2004/2004-12.pdf

VDE

(continua)

Attivare un plug per il funzionamento della rete

Attivare sul server students tappo una connessione del plug appena creato

Eseguire UML con le opzioni di rete

pippo# PATH = $PATH:/home/students/COURSES/labso/UML

pippo# vde_switch -daemon -unix /tmp/nome_gruppo.vde

Dove nome_gruppo è il nome che si decide di dare al plug. Può essere utilizzato più volte

pippo# dpipe ssh nome_gruppo@tappo.students vde_plug = vde_plug /tmp/nome_gruppo.vde

VDE

(continua)

Eseguire UML con le opzioni di rete

pippo# linux+ con1=null ubd0=file_cow.cow eth0=daemon,,,/tmp/nome_gruppo.vde

Una volta inserita la password, la shell da cui è stato lanciato il comando rimane occupata. Eventualmente, il comando può essere lanciato in background (& finale). Il processo non va terminato prima della conclusione del lavoro sul filesystem virtuale pena il mal funzionamento della rete.

Prima di terminare la propria sessione di lavoro, occorre terminare il processo generato da “dpipe” insieme a quelli attivati da vde:

pippo# killall vde_switch vde_plug

DISPOSITIVI

Ogni dispositivo accessibile dalla macchina virtuale è a sua volta virtuale. E’ costruito a partire da astrazioni appropriate fornite dall’host.

CONSOLE AND SERIAL LINE :

Console e linee seriali sono dispositivi fisici distinti

MACCHINA REALE

MACCHINA VIRTUALE UML

Non esiste distinzione reale: console e linee seriali condividono la maggior parte del loro codice

DISPOSITIVI

DISPOSITIVI A BLOCCHI :

Esiste un unico driver a blocco che fornisce accesso a qualsiasi cosa presente sull’host che possa essere montato

(continua)

DISPOSITIVI DI RETE :

Esiste un unico driver di rete che, attraverso un certo numero di backend, fornisca l’accesso alla rete. I backend comprendono ethertap, TUN/TAP, daemon, ecc.

I backend ethertap e TUN/TAP scambiano frame ethernet con l’host e la rete esterna. Il demone di routing può essere usato per settare una ethernet totalmente virtuale senza connessioni con l’host.

EMULAZIONE DELLA

MEMORIA VIRTUALE

UML implementa le esigenze reali di Linux di avere accesso a

memoria fisica della piattaforma

memoria virtuale del kernel

spazio di indirizzamento virtuale per ogni processo

Creando un file fisico di memoria dimensionata e mappandolo come un blocco nel proprio spazio di indirizzamento.

Il resto del kernel e i dati sono localizzati nello spazio di indirizzamento dei processi.

La memoria virtuale di kernel e processi è implementata mappando le pagine individuali da questo file nel posto appropriato nello spazio di indirizzamento virtuale.

EMULAZIONE DELLA

MEMORIA VIRTUALE

Il kernel mantiene un contesto di memoria separato per ogni processo, rendendo impossibile per ogni processo accedere alla memoria di proprietà di un altro.

Quando un processo ha bisogno di memoria, la pagina verrà allocata a partire da tale area e le pagine corrispondenti nel file verranno mmapped() nella memoria virtuale del processo

Il kernel nativo asseconda questo allocando pagine fisiche e mappandole a livello hardware nella locazione appropriata all’interno di una memoria virtuale di processo.

Uml emula questo creando un file che ha la stessa dimensione della memoria fisica assegnatagli e quindi mappando questo file come un buco in un’area della propria memoria virtuale che verrà tratta come memoria fisica.

(continua)

EMULAZIONE DI

TRAP E INTERRUPT

TRAP E FAULT :

Un trap del processore è un meccanismo che può causare l’ingresso di un processo in kernel mode. UML implementa ciò tramite SIGNAL Linux.

Ingresso e uscita dalla modalità kernel sono simili al caso delle system call.

Quando un processo riceve un SIGNAL, il thread di tracciamento lo riconosce prima del processo stesso. Il processo prosegue la propria esecuzione in kernel mode ma senza che il suo stato venga salvato né imporre alcun nuovo stato.

UML stabilisce handler suoi propri per ogni SIGNAL di rilievo.

EMULAZIONE DI

TRAP E INTERRUPT

DEVICE INTERRUPT :

Interrupt da dispositivi esterni son oimplementati tramite SGIO. I driver fanno in modo che quando arriva l’input venga generato SGIO

(continua)

L’handler SGIO identifica quali file descriptor stiano aspettando input e determina quale IRQ sia associato ad ogni descrittore.

Per rilevare l’interrupt, è invocato il codice IRQ standard.

EMULAZIONE DI

TRAP E INTERRUPT

(continua)

TIMER INTERRUPT :

Il clock è implementando usando il timer Linux. Esso invia SIGLRM o SIGVTALRM a seconda se il processo che ha ricevuto l’interupt sia o meno un thread idle

Il thread idle è messo a dormire e deve ricevere SIGALARM per essere risvegliato

Gli altri no

MEMORY FAULT :

E’ implementato tramite SIGSEGV. Quando un processo UML esegue un accesso non valido inmemoria, l’host genererà un SIGSEGV per esso

CONTEXT SWITCH

Ogni processo UML possiede un proprio thread nel kernel host.

Un context switch da un processo a un altro implica arrestare il processo uscente e far proseguire quello entrante

Ogni processo UML possiede un proprio spazio di indirizzamento. Ciò accelera il context switch.

Le pagine del processo entrante devono essere unmappate e riutilizzate una volta che esso è stato switchato fuori

Il processo host avrà ancora le proprie mappate perciò è necessario unmapparle prima che gli sia permesso di tornare in user space.

Tali pagine vengono identificate da una coppia di bit che vengono di volta in volta settati in modo appropriato e cancellati quando l’host mapping è aggiornato.

Una sottigliezza: SIGIO verrà accodato al processo registrato come suo recipiente di notifica asincrona. Quando si verifica un context switch, tale registrazione SIGIO deve essere modificata dal processo uscente per quello entrante.

INDIRIZZI UTILI

NETKIT: progetto dell’Università di Roma3 nel contesto dell’insegnamento di programmazione di rete, realizza una rete completamente simulata tramite nodi UML.

UML: Pagina ufficiale del progetto

HTTP://www.netkit.org

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

HTTP://sourceforge.net/projects/user-mode-linux

UML: User Mode Linux Home Page

Nessun titolo diapositiva

2005-03-21T10:24:11