16
UNIVERSITATEA POLITEHNICA BUCURESTI FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI Masini virtuale VMM POSTOLACHE DANIEL-RELU MASTER IISC anul I 2013

Masini virtuale VMM - stst.elia.pub.rostst.elia.pub.ro/news/SOA/Teme_SOA_12_13/PostolacheDaniel/Masini... · controlata. Majoritatea acestor operatii sunt operatii intrare/iesire

  • Upload
    others

  • View
    38

  • Download
    5

Embed Size (px)

Citation preview

UNIVERSITATEA POLITEHNICA BUCURESTI

FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI

Masini virtuale

VMM

POSTOLACHE DANIEL-RELU

MASTER IISC anul I

2013

2

CUPRINS

1 INTRODUCERE ……………………………………………………………………………………………………………………..

2 MICROKERNELUL .......................................................................................................................

2.1 Componente esentiale ale microkernelului ……………………………………………………………

2.2 Comunicarea inter-procese (IPC) ……………………………………………………………………………

2.3 Microkernelul L4 ………………………………………………………………………………………………….

3 REPREZENTAREA UNEI MASINI VIRTUALE …………………………………………………………………………..

4 RESURSELE MASINII VIRTUALE…………………………………………………………………………………………….

5 PROTECTIA RESURSELOR …………………………………………………………………………………………………….

5.1 Tipuri de mecanisme de protectie ………………………………………………………………………..

5.2 Mecanisme statice de protectie ……………………………………………………………………………

6 BIBLIOGRAFIE …………………………………………………………………………………………………………………….

3

1 INTRODUCERE

Masinile virtuale, introduse pentru prima data de catre IBM in anii 60, isi propun sa asigure unor

multipli utilizatori un sistem de calcul care sa depaseasca limitele impuse catre sistemele clasice

orientate catre un singur user. In ultimii 40 de ani, acestea au evoluat atat de mult, incat in prezent sunt

capabile de a asigura refolosirea completa a nivelelor software pentru a permite rezolvarea unor

varietati de probleme cum ar fi : exploatarea unor noi caracteristici hardware, reutilizarea driverelor de

dispozitiv sau securitatea crescuta.[6]

Sistemele de operare orientate pe componente reusesc sa creasca flexibilitatea software-ului

prin separarea sistemului de operare in diferite componente si izolarea lor. Baza fiecarui sistem il

reprezinta microkernelul, iar acest microkernel asigura cerintele minimale precum calculul, izolarea si

comunicarea dintre componente, pentru a asigura independenta si integritatea subsistemelor create.

Astfel, microkernelul reprezinta cantitatea minima de software ce poate asigura mecanismele necesare

pentru implementarea unui sistem de operare. Scopul acestuia este acela de a permite constructia unor

sisteme arbitrare in varful acestei piramide architecturale.

In cadrul masinilor virtuale putem vorbi despre doua tipuri de arhitecturi: o arhitectura

supervizata (Hypervisor Arhitecture) si una gazduita (Hosted Arhitecture). Sistemele bazate doar pe una

dintre aceste arhitecturi sunt deseori restrictive si nu ofera o flexibilitate suficienta. Un hypervisor

privilegiat asigura baza unui sistem fiabil, acesta implementand o singura interfata si anume masina

virtuala. Masinile virtuale sunt izolate intre ele si executate in siguranta folosind resursele masinii gazda,

dar acestea nu pot fi considerate reprezentari identice a unei masini reale intrucat nu pot reprezenta si

cele mai mici componente software efficient. O super masina virtuala va fi cea care va implementa

servicii catre celelalte componente. Pentru a depasi limitarile impuse de aceasta logica a

managementului masinilor virtuale, se foloseste o abordare bazata pe host si care integreaza

hypervisorul privilegiat intr-un sistem de operare gazda ce este executat direct pe masina fizica.

Serviciile acestui sistem de operare gazda sunt folosite pentru a implementa monitorul masinii virtuale si

alte aplicatii la nivel de user.

Concentrandu-se pe refolosirea si izolarea componentelor, masinile virtuale nu ofera

abstractizarea componentelor ce tin de comunicarea cu sistemele ce inconjoara masina virtuala. Aceasta

este deseori emulata folosind dispositive speciale ce sunt parte a platformei oferite de catre masina

gazda. Microkernelul pe de alta parte, a fost proiectat pentru a oferi un sistem de baza flexibil, definind

o interfata avantajoasa catre aplicatiile la nivel de utilizator. In cadrul lucrarii de fata, vom analiza modul

in care mediul masinii virtuale si al microkernelului pot fi unificate pentru a asigura un sistem fiabil, cu

un management al resurselor care sa virtualizeze intr-un mod cat mai eficient un sistem de calcul real.

4

2 MICROKERNELUL

2.1 Componente esentiale ale microkernelului

Componenta centrala a unei masini virtuale este kernelul, acesta fiind o componenta speciala ce

este creata atunci cand masina virtuala este pornita si care ramane in memorie dupa momentul pornirii.

Rolul acestuia este de a manageria resursele sistemului si de expune interfele uniform astfel incat

aplicatiile la nivel de utilizator ce ruleaza pe masina virtuala sa poata interactiona cu kernelul sistemului.

Microkernelul defineste doua tipuri de interfete, conectorii si serviciile, pentru aplicatiile cu care doreste

sa comunice. Conectorii sunt proiectati pentru a fi folositi pentru interactiile pe termen lung cu obiecte

precum fisiere, in timp ce serviciile sunt folosite pentru interogari simple. Interfetele de tip conector

importa operatii de tip plugin si exporta operatii de tip plugout, iar pentru a fi folosite este necesara

stabilirea unor timpi de executie a conexiunilor.[7]

[1]Microkernelul a fost dezvoltat in anii 1980 ca un raspuns la schimbarile masive ce guvernau

domeniul sistemelor de calcul, permitand noilor drivere de program, noilor protocoale si noilor sisteme

de fisiere ce erau dezvoltate la acea vreme, sa fie implementate ca si programe in spatiul utilizatorului,

la fel ca orice alt program. Microkernelul urma sa asigure dezvoltarea acestora pe sistemele monolitice

si sa permita pornirea si oprirea lor ca orice alt program din cadrul sistemului respectiv. De asemenea,

acesta ar fi permis separarea codului kernel pentru a fi imbunatatit in detaliu, fara grija posibilelor

efecte secundare, si construirea unor noi sisteme de operare pe un nucleu comun.

Kernelul sistemelor de operare incipiente era destul de mic, acest lucru datorandu-se memoriei

limitate existente. De-a lungul timpului capabilitatea calculatorarelor a crescut, crescand implicit si

numarul de dipozitive controlate de catre kernel. De-a lungul istoriei timpurii ale Unix-ului, kernelul era

in general de dimensiuni mici, desi continea drivere de dispozitiv si manageri ale sistemelor de fisiere.

Atunci cand spatiul de adrese a crescut de la 16 la 32 de biti, designul kernelului nu a mai fost limitat de

arhitectura hardware, iar astfel acesta a inceput sa creasca.[6]

Microkernelul a fost proiectat pentru a adresa cresterea accentuata a kernelelor si dificultatile

generate de acest lucru. In teorie, modelul unui microkernel permite un management mai usor al

codului datorita divizarii acestuia in servicii la nivel de utilizator. Acest lucru permite de asemenea si o

securitate crescuta si o stabilitate ce rezulta din cantitatea redusa de cod ce ruleaza in modul kernel.

O masina virtuala bazata pe microkernel este analoga unui sistem de operare bazat pe

microkernel. Orice operatie potential sensitiva trebuie sa fie inclusa in kernel pentru a fi astfel

controlata. Majoritatea acestor operatii sunt operatii intrare/iesire precum deschiderea de fisiere sau

conexiunile de retea. Pentru a minimiza dimensiunea kernelului, nu este necesar a se plasa intreaga

librarie I/O in kernel, ci doar operatiile de sistem aflate la cel mai de jos nivel.

5

Figura 1 : Arhitectura layered a unei masini virtuale

In modelul lansat de IBM, masinile virtuale reprezinta copii identice ale hardware-ului gazda,

unde fiecare instanta ruleaza propiul sistem de operare. Multiple masini virtuale pot fi create si

manageriate cu ajutorul interfetelor exportate de catre un Virtual Machine Monitor(VMM), aceasta

reprezentand o componenta ce ruleaza pe hardware-ul fizic. [2]Cum masinile virtuale pot fi detinute de

multipli utilizatori, VMM ofera mecanisme puternice de izolare a resurselor, fiind de asemenea

insarcinat cu partajarea componentei hardware si permitand multiplexarea mai multor masini virtuale

peste un singur set de resurse fizice.

O caracteristica importanta a monitoarelor de masini virtuale este abilitatea acestora de a

suporta executia aplicatiilor “out of the box”, utilizatorii putand rula cod executabil pe propiile sisteme

de calcul. Linux in modul utilizator permite virtulizarea la nivel de software prin rularea VMM ca o

aplicatie inauntrul unui sistem Linux gazda. Astfel se poate spune ca VMM si microkernelul prezinta o

serie larga similaritati arhitecturale, iar ultimile cercetari isi propun dezvoltarea functionalitatii VMM

peste microkernelul L4.[2]

6

2.2 Comunicarea inter-procese (IPC)

Comunicarea inter-procese ( Inter-process communication – IPC) reprezinta mecanismul ce

permite unor procese separate sa comunice intre ele, prin intermediul unor mesaje. La aparitia masinilor

virtuale abrevierea IPC se referea strict transmiterea mesajelor, urmand ca aceasta sa capete o

deosebita semnificatie in dezvoltarea microkernelului dupa. [4] IPC permite ca sistemul de operare sa fie

construit dintr-un numar de programe mici numite servere, ce vor fi folosite de catre alte programe din

cadrul sistemului.

Comunicarea inter-procese poate fi de doua tipuri: sincrona si asincrona. Prima generatie de

microkernel-uri suporta de obicei atat mecanismul sincron cat si cel asincron, insa erau afectate de catre

performanta slaba pe care acestea le ofereau. A doua generatie de kerneluri, L4, isi propunea sa

identifice problemele ce tineau de designul si implementarea IPC si sa imbunatateasca indicii de

performanta ale acestui mecanism. Astfel, noul sistem IPC urma sa suporte atat trimiterea cat si

primirea de operatii, totul realizandu-se sincron si trecand cat mai multe date prin registri. De

asemenea, a fost introdus conceptul de schimbare directa a proceselor, unde in cadrul unei executii IPC

era posibila schimbarea contextului de la emitator direct catre receptor.

Deoarece comunicarea pe baza de masaje dintre componentele sistemului este cruciala pentru

orice microkernel, exista numeroase studii ce au ca scop masurarea performantei IPC , imbunatatirea

acesteia sau daca aceasta este sau nu relevanta. Insa vom vedea ca, un mecanism IPC rapid nu este

neaparat o caracteristica de design critica in constructia unor monitoare de masini virtuale.

Exista numeroase motive pentru care putem evita dependenta de mecanisme IPC sincrone si

rapide. Intrucat pentru VMM izolarea componentelor este sarcina principala, comunicarea inter-procese

dintre masinile virtuale nu este atat de generala, acest lucru fiind o consecinta naturala a faptului ca

designul monitorului de masina virtuala considera intregul sistem de operare ca fiind o unitate

planificata si protejata.[6]

2.3 Microkernelul L4

Microkernelul L4 reprezinta o a doua generatie de microkerneluri, aceasta fiind dezvoltata

pentru a rezolva problemele de performanta aparute in cadrul sistemelor de operare care aveau la baza

prima generatie de microkernel si avand ca scop o securitate si o izolare a componentelor imbunatatita,

care sa nu depinda de platforma pe care ruleaza. Numele L4 este unul generalizat, nucleul binar original

cunoscand numeroase reimplementari precum : L4Ka::Pistachio,L4/MIPS sau Fiasco.Noul microkernel

era mult mai mic acesta asigurand cele 4 mecanisme de baza : spatiile de adrese, firele de executie,

planificarea si comunicarea inter-procese sincrona. [5]

7

Un fir de executie reprezinta abstractizarea unei activitati, iar la nivelul microkernelului L4

acesta este reprezentat de catre propria stare a registrului(registri de procesor si registri virtuali), de

catre un identificator global unic si de catre un spatiu de adrese asociat. Un spatiu de adrese asigura

abstractizarea necesara pentru protectia si izolarea resurselor, spatiile de adrese L4 nefiind obiecte de

prima clasa. [5]Acestea sunt indirect identificate cu ajutorul unui fir de executie asociat spatiului

respectiv, iar astfel toate firele de executie dintr-un anumit spatiu de adrese vor avea aceleasi drepturi si

se pot manipula reciproc. Comunicarea inter-procese reprezinta mecanismul cel mai important in

designul unui microkernel acesta fiind responsabil pentru transferul datelor si pentru transferul

controlat al executiei intre fire. Transferul de mesaje are loc sincron, intre exact doua fire de executie,

atat emitatorul cat si receptoul mesajului putand decide asupra formatului mesajului ce urmeaza a fi

transmis. De asemenea, un microkernel L4 prezinta un planificator intern, bazat pe un algoritm de tip

round-robin, ce are ca sarcina alocarea de timpi pentru firele de executie, pe baza prioritatii acestora si a

intervalului de timp disponibil. Daca timpul alocat unui fir de executie expira, L4 goleste firul de

executie si planifica executia urmatorului fir.

Evenimentele generate de catre hardware precum exceptiile si intreruperile sunt convertite in

mesaje IPC generate de kernel. Atunci cand o intrerupere hardware are loc, kernelul sintetizeaza

mesajul intr-un fir de executie care este inregistrat ca fiind manipulatorul acelei intreruperi. Exceptiile

hardware sunt transparente catre firul de executie, kernelul pastrand contextul acestuia. Aceste exceptii

sunt mapate catre un procol de eroare bazat pe IPC, kernelul sintetizand mesajul cu informatia despre

cauza erorii si trimitandu-l catre un handler de tratare a exceptiei. Aceste protocoale permit

virtualizarea usoara a resurselor fizice.[6]

Asa cum am vazut pana in acest moment, o masina virtuala reprezinta o duplicare software si

hardware a unui sistem de calcul fizic, incluzand toate resursele platformei: procesorul, memoria

fizica/virtuala si dispositive. Reprezentarea unei masini virtuale presupune indeplinirea urmatoarelor

trei cerinte :

1. “Oaspetele” masinii virtuale necesita o duplicare eficienta si de incredere a sistemului masinii

fizice

2. Monitorul masiniii virtuale (VMM) necesita un control complet al masinii virtuale, in special al

resurselor fizice alocate si al executiei acestora

3. Microkernelul are nevoie de o reprezentare a resurselor masinii virtuale pentru a impune

anumite contrangeri asupra sistemului precum izolarea si integritatea.

Microkernelul L4 abstractizeaza o masina virtuala folosind un spatiu de adrese L4. Acest spatiu

detine toate resursele direct accesibile catre masina virtuala, permitand L4 si monitorului la nivel de

utilizator impunerea unei izolari stricte. Microkernelul L4 se asigura ca masina virtuala poate accesa

resursele numai cu permisiunea acestuia, stabilind astfel izolarea si independent, concepte cheie ale

microkernelului. L4 exporta de obicei o interfata de masina extinsa catre aplicatiile la nivel de utilizator.

Aceasta masina extinsa este similara, dar nu identica cu hardware-ul de la baza, L4 asigurand apeluri ale

sistemului si instalandu-se in fiecare spatiu de adrese virtual.[1]

La momentul crearii masinii virtuale, spatiul de adrese al acesteia este complet gol si nu are nicio

permisiune catre nicio resursa fizica. Acest lucru permite o izolare puternica a masinii virtuale, aceasta

putand opera numai cu resursele alocate explicit acesteia. Urmeaza ca monitorul masinii virtuale sa

8

populeze masina virtuala cu resursele acestuia, definitizand astfel mediul masinii virtuale. In functie de

tipul de resurse, L4 asigura implicit mecanismele necesare pentru redenumirea, multiplexarea si

emularea resurselor.

Figura 1 : Rolul microkernelului L4

3 REPREZENTAREA UNEI MASINI VIRTUALE

In continuare, vom urmari cum se pot folosi conceptele microkernelului L4 pentru a construi un

mediu eficient de masina virtuala. Arhitectura unei masini virtuale bazata pe microkernel este alcatuita

din trei componente majore: masina virtuala, monitorul acesteia si microkernelul. Masina virtuala

consta intr-un spatiu de adrese L4, ce contine toate resursele fizice ce pot fi direct accesibile si unde

unul sau mai multe fire de executie(thread-uri) reprezinta procesoarele masinii virtuale.

Monitorul, asa cum am vazut anterior in cadrul acestei lucrari, defineste si mentine mediul

masinii virtuale. Acesta garanteaza izolarea, controland intr-un mod securizat accesul masinii virtuale

catre resursele fizice si implementand toate aspectele complexe ale virtualizarii. Precum orice fir de

executie L4, monitorul poate beneficia de pe urma serviciilor ale altor componente la nivel de utilizator,

pentru a contrui mediul masinii virtuale( de exemplu : spatiul de stocare sau conectivitatea retelei).[1]

Microkernelul este cel ce ofera mediul de executie pentru masina virtuala, pentru monitor si

pentru restul sistemului. Acesta asigura executia controlata a guest-ului in masina virtuala, folosind

tehnici de virtualizare hardware atunci cand acestea sunt necesare.

Pentru a izola in mod sigur o masina virtuala, aceasta nu are permis un acces direct necontrolat

asupra resurselor hardware fizice ale sistemului gazda. In schimb, monitorul foloseste mapari catre

spatiul de adrese L4 pentru a permite accesul selectiv al masinii virtuale asupra unei resurse fizice.

9

Reprezentarea masinii virtuale reprezinta modulul major al monitorului masinii virtuale. Acesta

contine o detaliere completa a masinii virtuale incluzand resursele fizice alocate, manipularea

procesorului virtual, si emulatoarele de dispozitiv ce formeaza platform emulate a masinii.

Figura 2 : Reprezentarea masinii virtuale in monitorul la nivel de utilizator.

Procesorul este cel ce primeste toate evenimentele legate de virtualizare, modulul acestuia tratand

mesajele de virtualizare L4 si asigurand raspunsul. [4]Aplicatia de monitor trebuie sa fie capabila de a

controla executia procesoarelor masinii virtuale si de a tine evidenta status-ului executiei. In orice

moment al timpului un fir de executie VCPU poate fi intr-un din starile urmatoare:

- In starea de functionare, atunci cand un thread VCPU ruleaza un guest si il planifica ca pe orice

alt fir de executie din sistemul L4

- In starea de blocare, atunci cand un thread VCPU nu executa instructiunile guest-ului.

Monitorul masinii virtuale creeaza la inceput in mediu de pornire ce se supune standardului de

multiboot. Acest mediu trebuie sa ruleze microkernelul L4 ca pe un guest. Procesorul este setat in modul

protected cu paginarea dezactivata, iar monitorul copie imaginea sistemul de operare guest in memoria

fizica oaspete, instaland structurile de informatii multiboot. Dupa aceea, registrul VCPU-ului este

initializat, dupa standardul impus, folosind un mesaj virtualizat de raspuns pentru a porni thread-ul

VCPU. Majoritatea sistemelor de operare se bazeaza pe modul real de a executa primele etape ale

startup-ului. [1]

10

4 RESURSELE MASINII VIRTUALE

4.1 Memoria fizica

In continuare, vom urmari modul in care memoria fizica este reprezentata intr-un mediu de

masina virtuala bazat pe un microkernel L4. O masina virtuala nu poate avea acces direct catre memoria

fizica a sistemului gazda, deoarece la majoritatea arhitecturilor hardware accesul catre memoria fizica

este necontrolat, chiar si la procesoarele complet virtualizabile.Astfel, pentru a virtualiza memoria fizica

va fi folosita memoria virtuala, ce va permite controlul complet asupra accesului memoriei fizice a

masinii virtuale. Memoria virtuala permite remaparea memoriei fizice a masinii pentru a da fiecarei

masini virtuale iluzia unei bucati mari de memorie fizica ce porneste de la adresa zero. Aceasta va fi

suportata de catre hardware si va fi astfel foarte eficienta.[1]

Intr-un microkernel L4 spatiul memoriei virtuale este reprezentat de un spatiu de adrese.

Monitorul masinii virtuale va popula acest spatiu folosind mesaje L4 de mapare, mapand si asigurand

parti ale propriului spatiu de adrese catre spatiul masinii virtuale. Monitorul la nivel de user va putea

folosi paginarea la nivel de user a microkernelului L4 pentru a controla complet managementul

memoriei fizice pentru masina virtuala. Prin intermediul unui procol de eroare al paginilor din memorie,

monitorul este instiintat atunci cand apar erori la memoria fizica, iar prin procesul de mapare, acesta

poate asigura resursele de memorie necesare in locatii arbitrare cu drepturi diferite, oferind astfel un

control complet asupra memoriei fizice. Aceste mecanisme de mapare sunt extrem de flexibile pentru

masinile virtuale, acestea putand fi folosite pentru o partajare controlata a continutului. Din motive de

eficacitate, L4 nu ofera spatiul virtual complet de adrese catre utilizator, kernelul pastrand anumite

parti din el pentru propriile nevoi. Totusi nu exista limitari conceptuale in mecanismele de mapare care

ar putea impiedica administrarea intregului spatiu de adrese.

API-ul microkernelului L4 defineste doua obiecte obligatorii in fiecare spatiu de adrese : pagina

interfetei kernelului si aria blocului de control al firului de executie (UTCB). Locatia fiecarui obiect este

determinata de catre cel ce creeaza spatiul de adrese. Facand parte din spatiul virtual de adrese L4,

acestea apar ca obiecte in spatiu de adrese fizic al masinii virtuale. Monitorul poate defini in mod liber

pozitia acestora si prin urmare le poate “ascunde” de catre guest.[1]

11

Figura 2 : Ierarhia memoriei fizice : Monitorul la nivel de utilizator ( UL) foloseste memoria virtuala

pentru a asigura masinii virtuale virtualizarea memoriei fizice. L4 exporta memoria masinii prin

intermediul spatiul de adrese sigma zero. Monitorul poate solicita mapari ale memoriei catre propriul

spatiu de adrese si le poate transmite mai departe catre masina virtuala.

4.2 Memoria virtuala

Desi conceptul de management al memoriei virtuale L4 asigura spatiu fizic de adrese al masinii

virtuale, exista situatii in care sistemul de operare oaspete din cadrul masinii virtuale doreste crearea

proprie a memoriei virtuale. Pentru a mentine aceasta iluzie de acces catre memoria virtuala, sistemul

de masina virtuala trebuie sa transforme adresa virtuala a guest-ului intr-o adresa fizica a gazdei.

Aceasta tranformare are loc in doua etape: in prima etapa se translateaza adresa virtuala a guest-ului

intr-o adresa fizica a guest-ului cu ajutorul unor tabele de paginatie mentinute de catre sistemul de

operare oaspete, urmand ca in a doua etapa, monitorul sa mapeze adresele fizice ale guest-ului in

adrese fizice pentru gazda pentru a intari contrangerile aplicate asupra resurselor.

Majoritatea hardware-ului existent nu suporta aceasta translatie secventiala a memoriei. Pentru

o executie eficienta a acestora de catre procesorul fizic, ambele etape trebuiesc combinate intr-una

singura (shadow page-table) ce va translata direct adresele virtuale ale unui guest in adrese fizice ale

sistemului gazda. Acest tabel de paginatie shadow reprezinta o fuziune a doua tabele de paginatie,

reprezentand o combinatie a acestora ce poate fi comprehensibil din punct de vedere hardware si poate

permite executia fizica.

Intr-un sistem de virtualizare, generarea acestui tabel implica toate cele trei componente

majore arhitecturale. In primul rand, microkernelul trebuie sa aplice izolarea si independenta diferitelor

spatii de adrese ce contin aplicatiile si masinile virtuale. In al doilea rand, monitorul necesita un control

deplin asupra resurselor fizice ocupate de catre masina virtuala. In cele din urma, sistemul de operare

oaspete trebuie sa creeze spatii virtuale arbitrare de adrese in propria memorie fizica.[1]

4.3 Procesorul

12

Procesorul unei masini virtuale(VCPU) este critic pentru functionarea eficienta a unei masini

virtuale, iar acesta este reprezentat ca si un fir de executie. Un fir de executie reprezinta abstractizarea

unei portiuni de timp in care are loc multiplexarea mai multor procesoare fizice. Executia procesorului

unei masini virtuale poate fi controlata in acelasi mod in care este controlat orice alt fir de executie,

bazandu-se pe portiunile de timp alocate si pe prioritate. Pentru a isi multiplexa in mod sigur firele de

executie, L4 mentine procesorul ca si context in interiorul microkernelului. In timp ce executa direct

VCPU pe procesorul fizic, arhitectura procesorului virtualizabil ajuta la mentinerea izolarii si a controlului

asa cum a fost descris anterior in cadrul acestei lucrari.Monitorul necesita accesul la contextul

procesorului masinii virtuale intr-unul din cele doua cazuri:

a) Manipularea instructiunilor critice - pentru a emula resursele masinii virtuale precum anumiti

registri privilegiati sau anumite dispozitive, monitorul trebuie sa emuleze intructiunile ce

acceseaza aceste resurse.

b) Controlul asincron al executiei - atunci cand emuleaza comportamentul unor dispozitive active,

monitorul trebuie sa fie capabil sa modifice asincron starea VCPU-ului ( de exemplu, pentru a

introduce intreruperi virtuale de dispozitiv)

4.4 Dispozitivele periferice

Dispozitivele periferice sunt reprezentate ca o combinatie dintre memoria fizica, memoria IO si

liniile de intrerupere asociate la nivelul interfetei procesorului.

Dispozitivele cu memorie mapata

Aceste dispozitive sunt localizate in spatiul de adrese fizica ale guest-ului, fiind accesate cu

ajutorul unor operatiuni normale de incarcare. Accesul la aceste dispozitive este monitorizat cu ajutorul

unor pagini de eroare ce exista in memoria ce reprezinta dispozitivele respective.

Spatiul porturilor de intrare/iesire

[4]Pentru anumite arhitecturi(IA-32) exista de asemenea un spatiu aditional de adrese, numit

spatiul porturilor de intrare-iesire. Pentru microkernelul L4 aceste porturi de dispozitiv sunt parte din

abstractizarea la nivelul spatiului de adrese L4. Mapari de port special permit managementul

permisiunilor a unui spatiu de adrese asupra porturilor de intrare/iesire fizice.

Intreruperile

13

Microkernelul L4 abstractizeaza liniile de intrerupere a procesorului cu ajutorul unor fire de executie ale

kernelului special. Un sistem de masina virtuala trebuie sa faca fata urmatorelor doua tipuri de

intrerupere:

1) Intreruperi fizice ce provin de la dispozitive hardware reale

2) Intreruperi virtuale ce sunt create la nivelul unui dispozitiv software si care reprezinta un

dispozitiv emulate

DMA(Direct Acces Memory)

Folosind accesul direct la memorie intr-un sistem de masina virtuala, pot aparea anumite

probleme legate de izolarea resurselor. Pentru a mentine un control total si o izolare complete, accesul

direct la dispozitive de tip DMA pentru masinile virtuale trebuie sa fie impiedicat. Totusi, este posibil sa

se permita accesul la un dispozitiv DMA, dar prin intermendiul monitorului masinii virtuale ce detine

drepturile de a accesa dispozitivul respectiv. Microkernelul L4 nu necesita mecanisme ulterioare care sa

suporte acest tip de dispozitive intrucat un dispozitiv DMA poate fi controlat la nivel de utilizator cu

ajutorul monitorului, precum restul dispozitivelor, controland memoria fizica, liniile de intrerupere si

porturile de intrare/iesire.[4]

5 PROTECTIA RESURSELOR

5.1 Tipuri de mecanisme de protectie

In prezent sistemele de operare moderne sunt dependente puternic de mecanismele software

ce ajuta la protectia resurselor fata de utilizatori. In timp ce microprocesoarele tipice asigura mecanisme

hardware ieftine si efective pentru protejarea interfetelor, sistemele de operare sunt fortate sa

abstractizeze si sa virtualizeze aceste interfete pentru a exporta un set mai bogat de resurse precum

fisiere, socketuri, fire de executie sau console. Accesul catre aceste resurse este protejat aproape

intotdeauna prin verificari software, si nu hardware. Cum arhitecturile de procesor nu ofera un control

detaliat suficient asupra resurselor distribuite din sistem pentru a se asigura ca un program poate accesa

doar resursele pentru care este autorizat, mecanismele de protectie software nu numai ca devin

necesare, dar in acelasi timp ofera avantaje in plus, prin intarirea cerintelor de protectie a unui sistem

de operare. Pe alta parte, mecanismele hardware sunt deseori rigide, implicite, imprecise si nu au

acelasi grad de optimizare ca si cele software.[3]

Asadar, putem spune ca exista doua tipuri de mecanisme de protectie. Acelea care implicit restrang

abilitatea de a numi o resursa si cele care impiedica explicit o anumita resursa din a fi folosita in mod

14

eronat. In sistemele moderne aceste mecanisme sunt implementate atat in hardware, cat si in software

sub forma urmatoarelor:

a) Conditionale – permit un control detaliat al accesului prin intermediul unor declaratii de tip “if”

incorporate in codul sursa

b) Definirea domeniului de date – structuri de date per proces ce impiedica implicit setul de

resurse pe care un proces le poate accesa.

c) Spatiile de adrese – suport detaliat pentru a controla detaliat folosirea memoriei fizice

d) Protectia memoriei – suport detaliat pentru un control explicit al citirii, scrierii si executiei

accesului catre adrese existente.

Primele doua mecanisme sunt in mod evident mecanisme software, fiind aplicate de catre

programator sau de catre compilator. Aceste mecanisme reprezinta o logica aditionala pentru sistemele

de operare, asigurandu-se ca programele au un comportament corespunzator, respectand o semantica

de nivel inalt privind resursele distribuite.[3] Ultimele doua mecanisme sunt de obicei implementate in

forma hardware si asigura faptul ca programele nu impart portiuni mari de memorie ce nu ar trebui

impartite, dar permit totusi o distributie limitata a memoriei.

Alegerea unui anumit mecanism de protectie pentru o resursa particulara depinde atat de costul de

executie al implementarii hardware sau software, cat si de modul in care mecanismul respectiv este sau

nu oportun. Mecanismele hardware precum spatiile de adrese si protectia memoriei sunt potrivite in

situatii in care se doreste izolarea unor portiuni largi din memoria fizica, cand schimbarile legate de

protective sunt relativ infrecvente.

Protectia detaliata ce cunoaste schimbari frecvente sau protectia unor resurse ce nu pot fi

reprezentate prin portiuni invecinate ale memoriei sunt cel mai bine implementate folosind mecanisme

software, datorita flexibilitatii acestora, a costului de executie mai scazut si a usurintii in optimizare.

Exista o sinergie intre protectia oferita de hardware si software deopotriva. Mecanismele software se

bazeaza de obicei pe hardware ca fundatie, acesta garantandu-le propria integritate. In schimb,

schimbarile in protectia hardware sunt de obicei controlate si limitate cu ajutorul unor mecanisme

software. In mod specific, orice mecanism software care nu este protejat de un alt mecanism software

trebuie sa fie protejat din punct de vedere hardware, altfel devenind nefolositor.

5.2 Mecanisme statice de protectie

Rolul fundamental al unui mecanism de protectie este de a asigura o constragere asupra a ce

poate un anumit program sa faca. Daca acea constrangere poate fi specific atribuita, atunci mecanisme

aditionale de protectie precum cele descrise anterior devin nenecesare sau pot fi inlocuite cu unele mai

simple. Acest comportament poate fi usor de observat in implementarea interfetelor interne pentru

kernelul unui sistem de operare. Pentru aceste sisteme, codul kernelului asuma in mod implicit ca alte

bucati din kernel ce folosesc codul respectiv, respecta conventiile de apel ale sistemului, nu depasesc

15

referintele catre stiva alocata si nu definesc in mod necorespunzator variabilele. Datorita acestor

presupuneri, implementarea kernelului poate fi simplificata pentru a evita anumite verificari privind

respectarea protectiei.[3]

Mecanismele de protectie statice sunt posibile datorita existentei unui set de ipoteze privind

comportamentul codului. Daca putem presupune ca un cod nu a avut niciodata un comportament

malitios, atunci niciun mecanism de protectie nu mai este necesar. De asemenea, daca am putea

presupune ca acel cod nu a apela niciodata o resursa la care nu are acces, atunci am putea elimina

verificarile complicate asupra accesului catre resurse. Mergand pe acest principiu si facand in

continuare astfel de presupuneri despre modul in care codul sursa functioneaza , putem imbunatati

structura si perfomanta codului sistemului specializat si contruit incremental.

6 BIBLIOGRAFIE

16

[1] Sebastian Biemuller, Hardware-Supported Virtualization for the L4 Microkernel, pag. 17-25,

Septembrie 2006

[2] Steven Hand, Andrew Warfield, Keir Fraser, Evangelos Kotsovinos, Dan Magenheimer, Are

Virtual Machines Monitors Microkernels Done Right?, 2005

[3] Brian Bershad, Stefan Savage, Przemyslaw Pardyak, David Becker, Marc Fiuczynsky,

Protection is a Software Issue, Dept. of Computer Science and Engineering, University of

Washington, 2002

[4] Xiaoqi Lu, Scott Smith, A Secure Microkernel Virtual Machine, Department of Computer

Science, The Johns Hopkins University, 2005

[5] http://en.wikipedia.org/wiki/L4_microkernel_family

[6] http://en.wikipedia.org/wiki/Microkernel

[7] http://www.kernel.org/doc/Documentation/