Virutalizacao2

8/6/2019 Virutalizacao2

1/49

Captulo

4Virtualizao: Conceitos e Aplicaesem Segurana

Marcos Aurelio Pchek Laureano1,2, Carlos Alberto Maziero1

1Programa de Ps-Graduao em InformticaPontifcia Universidade Catlica do ParanCuritiba PR

2Centro Universitrio Franciscano (UNIFAE)Curitiba PR

Abstract

The recent evolution of the virtual machines technology allowed their large-scale

adoption in production systems. Currently, the main use of virtual machines has been the

servers consolidation, aiming at reducing hardware, software, and management costs

of the installed computing infrastructure. However, in the recent years, several research

works showed many possibilities of using virtual machines in the systems security area.

This work presents the fundamental concepts about virtual machines, discusses advan-

tages and drawbacks of using virtual machines in several application domains, explores

the usage possibilities of virtual machines in the systems security area, and shows some

examples of popular virtual machine environments.

Resumo

A evoluo recente da tecnologia de mquinas virtuais permitiu a sua adoo em

larga escala nos sistemas de produo. O principal uso de mquinas virtuais tem sido a

consolidao de servidores e, conseqentemente, a reduo de custos em hardware, soft-

ware e gerncia do parque tecnolgico. No entanto, vrias pesquisas vm demonstrando

possibilidades de aplicao de mquinas virtuais na rea de segurana de sistemas. Este

trabalho apresenta os fundamentos conceituais sobre mquinas virtuais, discute as van-

tagens e desvantagens no uso de mquinas virtuais, explora as principais possibilidadesde uso de mquinas virtuais na rea de segurana de sistemas e expe alguns exemplos

de ambientes de mquinas virtuais de uso corrente.


2/49

4.1. Introduo virtualizao

O conceito de mquina virtual no recente. Os primeiros passos na construo de am-

bientes de mquinas virtuais comearam na dcada de 1960, quando a IBM desenvol-veu o sistema operacional experimental M44/44X. A partir dele, a IBM desenvolveuvrios sistemas comerciais suportando virtualizao, entre os quais o famoso OS/370[Goldberg 1973, Goldberg and Mager 1979]. A tendncia dominante nos sistemas na-quela poca era fornecer a cada usurio um ambiente mono-usurio completo, com seuprprio sistema operacional e aplicaes, completamente independente e desvinculadodos ambientes dos demais usurios.

Na dcada de 1980, com a popularizao de plataformas de hardware baratascomo o PC, a virtualizao perdeu importncia. Afinal, era mais barato, simples e verstilfornecer um computador completo a cada usurio, que investir em sistemas de grande

porte, caros e complexos. Alm disso, o hardware do PC tinha desempenho modesto eno provia suporte adequado virtualizao, o que inibiu o uso de ambientes virtuaisnessas plataformas.

Com o aumento de desempenho e funcionalidades do hardware PC e o surgimentoda linguagem Java, no incio dos anos 90, o interesse pelas tecnologias de virtualizaovoltou tona. Apesar da plataforma PC Intel ainda no oferecer um suporte adequado virtualizao, solues engenhosas como as adotadas pela empresa VMWare permitirama virtualizao nessa plataforma, embora com desempenho relativamente modesto. Atu-almente, as solues de virtualizao de linguagens e de plataformas vm despertandogrande interesse do mercado. Vrias linguagens so compiladas para mquinas virtuais

portveis e os processadores mais recentes trazem um suporte nativo virtualizao.

4.1.1. Arquitetura dos sistemas computacionais

Uma mquina real formada por vrios componentes fsicos que fornecem operaespara o sistema operacional e suas aplicaes. Iniciando pelo ncleo do sistema real, oprocessador central (CPU) e o chipset da placa-me fornecem um conjunto de instruese outros elementos fundamentais para o processamento de dados, alocao de memriae processamento de entrada/sada. Os sistemas de computadores so projetados com ba-sicamente trs componentes: hardware, sistema operacional e aplicaes. O papel dohardware executar as operaes solicitadas pelas aplicaes atravs do sistema operaci-

onal. O sistema operacional recebe as solicitaes das operaes (por meio das chamadasde sistema) e controla o acesso ao hardware principalmente nos casos em que os compo-nentes so compartilhados, como o sistema de memria e os dispositivos de entrada/sada.

Os sistemas de computao convencionais so caracterizados por nveis de abs-trao crescentes e interfaces bem definidas entre eles. Um dos principais objetivos dossistemas operacionais oferecer uma viso abstrata, de alto nvel, dos recursos de hard-ware, que sejam mais simples de usar e menos dependente das tecnologias subjacentes.As abstraes oferecidas pelo sistema s aplicaes so construdas de forma incremental,em nveis separados por interfaces bem definidas e relativamente padronizadas. Cada in-terface encapsula as abstraes dos nveis inferiores, permitindo assim o desenvolvimentoindependente dos vrios nveis, o que simplifica a construo e evoluo dos sistemas.


3/49

Exemplos tpicos dessa estruturao em nveis de abstrao crescentes, separadospor interfaces bem definidas, so os subsistemas de rede e de disco em um sistema ope-

racional convencional. No sub-sistema de arquivos, cada nvel de abstrao trata de umproblema: interao com o dispositivo fsico de armazenamento, escalonamento de aces-sos ao dispositivo, gerncia de buffers e caches, alocao de arquivos, diretrios, controlede acesso, etc. A figura 4.1 apresenta os nveis de abstrao de um subsistema de gernciade disco tpico.

Figura 4.1. Nveis de abstrao em um sub-sistema de disco.

As interfaces existentes entre os componentes de um sistema de computao so:

Conjunto de instrues ( ISA Instruction Set Architecture): a interface bsicaentre o hardware e o software, sendo constituda pelas instrues em cdigo demquina aceitas pelo processador e todas as operaes de acesso aos recursos dohardware (acesso fsico memria, s portas de entrada/sada, ao relgio do sis-tema, etc.). Essa interface dividida em duas partes:

Instrues de usurio (User ISA): compreende as instrues do processador edemais itens de hardware acessveis aos programas do usurio, que executamcom o processador operando em modo no-privilegiado;

Instrues de sistema (System ISA): compreende as instrues do processa-dor e demais itens de hardware, unicamente acessveis ao ncleo do sistemaoperacional, que executa em modo privilegiado;

Chamadas de sistema (syscalls): o conjunto de operaes oferecidas pelo n-cleo do sistema operacional aos processos dos usurios. Essas chamadas permitemum acesso controlado das aplicaes aos dispositivos perifricos, memria e s

instrues privilegiadas do processador.


4/49

Chamadas de bibliotecas (libcalls): bibliotecas oferecem um grande nmero defunes para simplificar a construo de programas; alm disso, muitas chamadas

de biblioteca encapsulam chamadas do sistema operacional, para tornar seu usomais simples. Cada biblioteca possui uma interface prpria, denominada Interfacede Programao de Aplicaes (API Application Programming Interface). Exem-plos tpicos de bibliotecas so a LibCdo UNIX (que oferece funes como fopene printf), a GTK+ (Gimp ToolKit, que permite a construo de interfaces grfi-cas) e a SDL (Simple DirectMedia Layer, para a manipulao de udio e vdeo).

A figura 4.2 apresenta essa viso conceitual da arquitetura de um sistema compu-tacional, com seus vrios componentes e as respectivas interfaces entre eles.

Figura 4.2. Componentes e interfaces de um sistema computacional.

4.1.2. Compatibilidade entre interfaces de sistema

Para que programas e bibliotecas possam executar sobre uma determinada plataforma, necessrio que tenham sido compilados para ela, respeitando o conjunto de instruesdo processador em modo usurio (User ISA) e o conjunto de chamadas de sistema ofe-recido pelo sistema operacional. A viso conjunta dessas duas interfaces (User ISA +syscalls) denominada Interface Binria de Aplicao (ABI Application Binary Inter-

face). Da mesma forma, um sistema operacional s poder executar sobre uma plataformade hardware se tiver sido construdo e compilado de forma a respeitar sua interface ISA(User/System ISA). A figura 4.3 representa essas duas interfaces.

Figura 4.3. Interfaces de sistema ISA e ABI [Smith and Nair 2004].


5/49

Nos sistemas computacionais de mercado atuais, as interfaces de baixo nvel ISAe ABI so normalmente fixas, ou pouco flexveis. Geralmente no possvel criar novas

instrues de processador ou novas chamadas de sistema operacional, ou mesmo mudarsua semntica para atender s necessidades especficas de uma determinada aplicao.Mesmo se isso fosse possvel, teria de ser feito com cautela, para no comprometer ofuncionamento de outras aplicaes.

Os sistemas operacionais, assim como as aplicaes, so projetados para apro-veitar o mximo dos recursos que o hardware fornece. Normalmente os projetistas dehardware, sistema operacional e aplicaes trabalham de forma independente (em empre-sas e tempos diferentes). Por isso, esses trabalhos independentes geraram, ao longo dosanos, vrias plataformas computacionais diferentes e incompatveis entre si.

Observa-se ento que, embora a definio de interfaces seja til, por facilitar o

desenvolvimento independente dos vrios componentes do sistema, torna pouco flexveisas interaes entre eles: um sistema operacional s funciona sobre o hardware (ISA) parao qual foi construdo, uma biblioteca s funciona sobre a ABI para a qual foi projetadae uma aplicao tem de obedecer a ABIs/APIs pr-definidas. A figura 4.4, extrada de[Smith and Nair 2004], ilustra esses problemas de compatibilidade entre interfaces.

Figura 4.4. Problemas de compatibilidade entre interfaces [Smith and Nair 2004].

A baixa flexibilidade na interao entre as interfaces dos componentes de um sis-tema computacional traz vrios problemas [Smith and Nair 2004]:

Baixa portabilidade: a mobilidade de cdigo e sua interoperabilidade so requisitosimportantes dos sistemas atuais, que apresentam grande conectividade de rede ediversidade de plataformas. A rigidez das interfaces de sistema atuais dificulta sua

construo, por acoplar excessivamente as aplicaes aos sistemas operacionais eaos componentes do hardware.


6/49

Barreiras de inovao: a presena de interfaces rgidas dificulta a construo denovas formas de interao entre as aplicaes e os dispositivos de hardware (e com

os usurios, por conseqncia). Alm disso, as interfaces apresentam uma grandeinrcia evoluo, por conta da necessidade de suporte s aplicaes j existentes.

Otimizaes inter-componentes: aplicaes, bibliotecas, sistemas operacionais ehardware so desenvolvidos por grupos distintos, geralmente com pouca interaoentre eles. A presena de interfaces rgidas a respeitar entre os componentes levacada grupo a trabalhar de forma isolada, o que diminui a possibilidade de otimiza-es que envolvam mais de um componente.

Essas dificuldades levaram investigao de outras formas de relacionamento en-tre os componentes de um sistema computacional. Uma das abordagens mais promissoras

nesse sentido o uso de mquinas virtuais, que sero apresentadas na prxima seo.

4.1.3. Mquinas virtuais

Conforme visto, as interfaces padronizadas entre os componentes do sistema de com-putao permitem o desenvolvimento independente dos mesmos, mas tambm so fontede problemas de interoperabilidade, devido sua pouca flexibilidade. Por isso, no possvel executar diretamente em um processador Intel/AMD uma aplicao compiladapara um processador ARM: as instrues em linguagem de mquina do programa nosero compreendidas pelo processador Intel. Da mesma forma, no possvel executardiretamente em Linux uma aplicao escrita para Windows, pois as chamadas de sistema

emitidas pelo programa no sero compreendidas pelo sistema operacional subjacente.

Todavia, possvel contornar esses problemas de compatibilidade atravs de umacamada de virtualizao construda em software. Usando os servios oferecidos por umadeterminada interface de sistema, possvel construir uma camada de software que ofe-rea aos demais componentes uma outra interface. Essa camada de software permitir oacoplamento entre interfaces distintas, de forma que um programa desenvolvido para aplataforma A possa executar sobre uma plataforma distinta B (figura 4.5).

Figura 4.5. Acoplamento entre interfaces distintas

Usando os servios oferecidos por uma determinada interface de sistema, a ca-

mada de virtualizao constri outra interface de mesmo nvel, de acordo com as neces-sidades dos componentes de sistema que faro uso dela. A nova interface de sistema,


7/49

vista atravs dessa camada de virtualizao, denominada mquina virtual. A camada devirtualizao em si denominada hipervisor ou monitor de mquina virtual.

A figura 4.6, extrada de [Smith and Nair 2004], apresenta um exemplo de m-quina virtual, onde um hipervisor permite executar um sistema operacional Windows esuas aplicaes sobre uma plataforma de hardware Sparc, distinta daquela para a qualesse sistema operacional foi projetado (Intel/AMD).

Figura 4.6. Uma mquina virtual [Smith and Nair 2004].

Um ambiente de mquina virtual consiste de trs partes bsicas, que podem serobservadas na figura 4.6:

O sistema real, nativo ou hospedeiro (host system), que contm os recursos reais de

hardware e software do sistema;

o sistema virtual, tambm denominado sistema convidado (guest system), que exe-cuta sobre o sistema virtualizado; em alguns casos, vrios sistemas virtuais podemcoexistir, executando simultaneamente sobre o mesmo sistema real;

a camada de virtualizao, hipervisor, ou monitor(VMM Virtual Machine Moni-tor), que constri as interfaces virtuais a partir da interface real.

Originalmente, uma mquina virtual era definida como uma cpia efi-

ciente, isolada e protegida de uma mquina real [Popek and Goldberg 1974,Goldberg and Mager 1979]. Essa definio, vigente nos anos 1960-70, foi construda apartir da perspectiva de um sistema operacional: uma abstrao de software que gerenciaum sistema fsico (mquina real). Com o passar dos anos, o termo mquina virtualevoluiu e englobou um grande nmero de abstraes, como por exemplo a Java Virtual

Machine (JVM), que no virtualiza um sistema real [Rosenblum 2004].

A construo de mquinas virtuais bem mais complexa que possa parecer primeira vista. Caso os conjuntos de instrues do sistema real e do sistema virtual sejamdiferentes, necessrio usar as instrues da mquina real para simular as instruesda mquina virtual. Alm disso, necessrio mapear os recursos de hardware virtuais

(perifricos oferecidos ao sistema convidado) sobre os recursos existentes na mquinareal (os perifricos reais). Por ltimo, pode ser necessrio mapear as chamadas de sistema


8/49

emitidas pelas aplicaes do sistema convidado em chamadas equivalentes no sistemareal, quando os sistemas operacionais virtual e real forem distintos.

Existem vrias formas de implementar a virtualizao, que sero descritas nasprximas sees. Algumas delas so apresentadas sucintamente na figura 4.7, como:

Virtualizao completa: um sistema operacional convidado e suas aplicaes, de-senvolvidas para uma plataforma de hardware A, so executadas sobre uma plata-forma de hardware distinta B.

Emulao do sistema operacional: as aplicaes de um sistema operacional X soexecutadas sobre outro sistema operacional Y, na mesma plataforma de hardware.

Traduo dinmica: as instrues de mquina das aplicaes so traduzidas durantea execuo em outras instrues mais eficientes para a mesma plataforma.

Replicao de hardware: so criadas vrias instncias virtuais de um mesmo hard-ware real, cada uma executando seu prprio sistema operacional convidado e suasrespectivas aplicaes.

Figura 4.7. Possibilidades de virtualizao [Smith and Nair 2004].

4.1.3.1. Abstrao versus virtualizao

Embora a virtualizao possa ser vista como um tipo de abstrao, existe uma claradiferena entre os termos abstrao e virtualizao, no contexto de sistemas[Smith and Nair 2005]. A abstrao de recursos consiste em fornecer uma interface deacesso homognea e simplificada ao recursos do sistema. Por outro lado, a virtualizaoconsiste em criar novas interfaces a partir das interfaces existentes. Na virtualizao, osdetalhes de baixo nvel da plataforma real no so necessariamente ocultos, como ocorrena abstrao de recursos. A figura 4.8 ilustra essa diferena: atravs da virtualizao, umprocessador Sparc pode ser visto como um processador Intel. Da mesma forma, um disco

real no padro SATA pode ser visto como vrios discos menores independentes, com amesma interface (SATA) ou outra interface (IDE).


9/49

Figura 4.8. Virtualizao versus abstrao de recursos.

A figura 4.9 ilustra outro exemplo dessa diferena no contexto do armazenamentoem disco. A abstrao prov s aplicaes o conceito de arquivo, sobre o qual estaspodem executar operaes simples como read ou write, por exemplo. J a virtuali-zao fornece para a camada superior apenas um disco virtual, construdo a partir de umarquivo do sistema operacional real subjacente. Esse disco virtual ter de ser particionadoe formatado para seu uso, da mesma forma que um disco real.

Figura 4.9. Abstrao versus virtualizao de um disco rgido.

4.1.3.2. Propriedades dos hipervisores

Para funcionar de forma correta e eficiente, um hipervisor deve atender a alguns re-quisitos bsicos: ele deve prover um ambiente de execuo aos programas essencial-mente idntico ao da mquina real, do ponto de vista lgico. Programas executandosobre uma mquina virtual devem apresentar, no pior caso, leves degradaes de de-sempenho. Alm disso, o hipervisor deve ter controle completo sobre os recursos dosistema real (o sistema hospedeiro). A partir desses requisitos, foram estabelecidas por[Goldberg 1973, Popek and Goldberg 1974] as seguintes propriedades a serem satisfeitaspor um hipervisor ideal:

Equivalncia: um hipervisor prov um ambiente de execuo quase idntico ao damquina real original. Todo programa executando em uma mquina virtual deve se


10/49

comportar da mesma forma que o faria em uma mquina real; excees podem re-sultar somente de diferenas nos recursos disponveis (memria, disco, etc), depen-

dncias de temporizao e a existncia dos dispositivos de entrada/sada necessrios aplicao.

Controle de recursos: o hipervisor deve possuir o controle completo dos recursosda mquina real: nenhum programa executando na mquina virtual deve possuiracesso a recursos que no tenham sido explicitamente alocados a ele pelo hiper-visor, que deve intermediar todos os acessos. Alm disso, a qualquer instante ohipervisor pode resgatar recursos previamente alocados.

Eficincia: grande parte das instrues do processador virtual (o processador pro-vido pelo hipervisor) deve ser executada diretamente pelo processador da mquinareal, sem interveno do hipervisor. As instrues da mquina virtual que no pu-derem ser executadas pelo processador real devem ser interpretadas pelo hipervisore traduzidas em aes equivalentes no processador real. Instrues simples, que noafetem outras mquinas virtuais ou aplicaes, podem ser executadas diretamenteno hardware.

Alm dessas trs propriedades bsicas, as propriedades derivadas a seguir sofreqentemente associadas a hipervisores [Popek and Goldberg 1974, Rosenblum 2004]:

Isolamento: esta propriedade garante que um software em execuo em uma m-quina virtual no possa ver, influenciar ou modificar outro software em execuo

no hipervisor ou em outra mquina virtual. Esta propriedade pode ser utilizada paragarantir que erros de software ou aplicaes maliciosas possam ser contidos em umambiente controlado (uma mquina virtual), sem afetar outras partes do sistema.

Inspeo: o hipervisor tem acesso e controle sobre todas as informaes do es-tado interno da mquina virtual, como registradores do processador, contedo dememria, eventos etc.

Gerenciabilidade: como cada mquina virtual uma entidade independente das de-mais, a administrao de diversas instncias de mquinas virtuais sobre um mesmosupervisor simplificada e centralizada. O hipervisor deve ter mecanismos para

gerenciar o uso dos recursos existentes entre os sistemas convidados. Encapsulamento: como o hipervisor tem acesso e controle sobre o estado interno

de cada mquina virtual em execuo, ele pode salvar checkpoints de uma mquinavirtual, periodicamente ou em situaes especiais (por exemplo, antes de uma atua-lizao de sistema operacional). Esses checkpoints so teis para retornar a mquinavirtual a estados anteriores (rollback), para anlises post-mortem em caso de falhas,ou para permitir a migrao da mquina virtual entre hipervisores executando emcomputadores distintos.

Recursividade: alguns sistemas de mquinas virtuais exibem tambm esta propri-

edade: deve ser possvel executar um hipervisor dentro de uma mquina virtual,produzindo um novo nvel de mquinas virtuais. Neste caso, a mquina real nor-malmente denominada mquina de nvel 0 (figura 4.10).


11/49

Figura 4.10. Diversos nveis de virtualizao [Laureano 2006]

Essas propriedades tambm podem ser utilizadas na segurana de sistemas[Honeynet Project 2003, Garfinkel and Rosenblum 2003] e outras aplicaes. As propri-edades bsicas caracterizam um hipervisor ideal, que nem sempre pode ser construdosobre as plataformas de hardware existentes. A possibilidade de construo de um hiper-visor em uma determinada plataforma definida atravs do seguinte teorema, enunciado

e provado por Popek e Goldberg em [Popek and Goldberg 1974]:

Para qualquer computador convencional de terceira gerao, um hipervisor

pode ser construdo se o conjunto de instrues sensveis daquele computa-

dor for um sub-conjunto de seu conjunto de instrues privilegiadas .

Para compreender melhor as implicaes desse teorema, necessrio definir cla-ramente os seguintes conceitos:

Computador convencional de terceira gerao: qualquer sistema de computaoconvencional seguindo a arquitetura de Von Neumann, que suporte memria virtuale dois modos de operao: modo usurio e modo privilegiado.

Instrues sensveis: so aquelas que podem consultar ou alterar o status do pro-cessador, ou seja, os registradores que armazenam o status atual da execuo namquina real;

Instrues privilegiadas: so acessveis somente por meio de cdigos executandoem nvel privilegiado (cdigo de ncleo). Caso um cdigo no-privilegiado tenteexecutar uma instruo privilegiada, uma exceo (interrupo) gerada, ativando

uma rotina de tratamento previamente especificada pelo ncleo do sistema real.


12/49

De acordo com esse teorema, toda instruo sensvel deve ser tambm privi-legiada. Assim, quando uma instruo sensvel for executada por um programa no-

privilegiado (um ncleo convidado ou uma aplicao convidada), provocar a ocorrnciade uma interrupo. Essa interrupo pode ser usada para ativar uma rotina de inter-pretao dentro do hipervisor, que ir simular o efeito da instruo sensvel (ou seja,interpret-la), de acordo com o contexto onde sua execuo foi solicitada (mquina vir-tual ou hipervisor). Obviamente, quanto maior o nmero de instrues sensveis, maior ovolume de interpretao de cdigo a realizar, e menor o desempenho da mquina virtual.

No caso de processadores que no atendam o teorema de Popek e Goldberg, po-dem existir instrues sensveis que executem sem gerar interrupes, o que impede ohipervisor de intercept-las e interpret-las. Uma soluo possvel para esse problema a traduo dinmica das instrues sensveis acessveis nos programas de usurio: ao

carregar um programa na memria, o hipervisor analisa seu cdigo e substitui as instru-es problemticas por chamadas a rotinas que as interpretam dentro do hipervisor. Issoimplica em um tempo maior para o lanamento de programas, mas torna possvel a vir-tualizao. Outra tcnica possvel para resolver o problema a para-virtualizao . Estastcnicas so discutidas na seo 4.1.5.

4.1.3.3. Suporte de hardware

Na poca em que Popek e Goldberg definiram seu principal teorema, o hardware virtua-lizvel dos mainframes IBM suportava parcialmente as condies impostas pelo mesmo.

Esses sistemas dispunham de uma funcionalidade chamada execuo direta, que per-mitia a uma mquina virtual acessar nativamente o hardware para execuo de ins-trues. Esse mecanismo permitia que aqueles sistemas obtivessem, com a utilizaode mquinas virtuais, desempenho similar ao de sistemas convencionais equivalentes[Goldberg 1973, Popek and Goldberg 1974, Goldberg and Mager 1979].

O suporte de hardware necessrio para a construo de hipervisores eficientes estpresente em sistemas de grande porte, mas apenas parcial nos micro-processadores demercado. Por exemplo, a famlia de processadores Intel Pentium IV (e anteriores) possui17 instrues sensveis que podem ser executadas em modo usurio sem gerar excees,o que viola o teorema de Goldberg e dificulta a criao de mquinas virtuais em sistemas

que usam esses processadores [Robin and Irvine 2000].Por volta de 2005, os principais fabricantes de micro-processadores (Intel e AMD)

incorporaram um suporte bsico virtualizao em seus processadores, atravs das tec-nologias IVT ( Intel Virtualization Technology) e AMD-V (AMD Virtualization), que soconceitualmente equivalentes [Uhlig et al. 2005]. A idia central de ambas as tecnologiasconsiste em definir dois modos possveis de operao do processador: os modos root enon-root. O modo root equivale ao funcionamento de um processador convencional, e sedestina execuo de um hipervisor. Por outro lado, o modo non-root se destina exe-cuo de mquinas virtuais. Alm de Intel e AMD, outros fabricantes de hardware tmse preocupado com o suporte virtualizao. Em 2005, a Sun Microsystems incorporou

suporte nativo virtualizao em seus processadores UltraSPARC [Yen 2007]. Em 2007,a IBM props uma especificao de interface de hardware denominada IBM Power ISA


13/49

2.04 [IBM 2007], que respeita os requisitos necessrios virtualizao do processador eda gesto de memria.

4.1.4. Tipos de mquinas virtuais

Conforme discutido na seo 4.1.3, existem diversas possibilidades de implementao desistemas de mquinas virtuais, cada uma com suas caractersticas prprias de eficinciae equivalncia. De acordo com o tipo de sistema convidado suportado, os ambientes demquinas virtuais podem ser divididos em duas grandes famlias (figura 4.11):

Mquinas virtuais de aplicao (Process Virtual Machines): so ambientes de m-quinas virtuais destinados a suportar apenas um processo ou aplicao convidadaespecfica. A mquina virtual Java e o ambiente de depurao Valgrind so exem-

plos desse tipo de ambiente. Mquinas virtuais de sistema (System Virtual Machines): so ambientes de mqui-

nas virtuais construdos para suportar sistemas operacionais convidados completos,com aplicaes convidadas executando sobre eles. Como exemplos, temos os am-bientes VMware e VirtualBox.

Figura 4.11. Mquinas virtuais de aplicao e de sistema.

Por outro lado, os ambientes de mquinas virtuais tambm podem ser classifica-dos de acordo com o nvel de similaridade entre as interfaces de hardware do sistemaconvidado e do sistema real (ISA):

Interfaces equivalentes: a interface virtual oferecida ao ambiente convidado repro-duz a interface de hardware do sistema real, permitindo a execuo de aplicaesconstrudas para o sistema real. Como a maioria das instrues do sistema convi-dado pode ser executada diretamente pelo processador (com exceo das instruessensveis), o desempenho obtido pelas aplicaes convidadas pode ser prximo do

desempenho de execuo no sistema real. Ambientes como VMware so exemplosdeste tipo de ambiente.


14/49

Interfaces distintas: a interface virtual no tem relao com a interface de hardwaredo sistema real, ou seja, implementa um conjunto de instrues distinto, a ser inter-

pretado pelo hipervisor. A interpretao de instrues impe um custo de execuosignificativo ao sistema convidado. O emulador QEMU, que prov s aplicaesum processador virtual Intel Pentium II, um exemplo desta abordagem.

A virtualizao tambm pode ser classificada como [Rosenblum 2004]:

Virtualizao do hardware: a virtualizao exporta o sistema fsico como hardwareabstrato (semelhante ao sistema original). Neste modelo, qualquer software escritopara a arquitetura nativa (x86, por exemplo) ir funcionar no sistema convidado.Este foi o modelo adotado na dcada de 60 para o VM/370 nos mainframes IBM e

a tecnologia de virtualizao utilizado pelo VMware na plataforma x86. Virtualizao do sistema operacional: a virtualizao exporta um sistema operacio-

nal como abstrao de um sistema especfico. A mquina virtual executa aplicaes ou um conjunto de aplicaes de um sistema operacional especfico. O FreeBSD

Jail ou o User-Mode Linux so exemplos desta tecnologia.

Virtualizao de linguagens de programao: a camada de virtualizao cria umaaplicao no topo do sistema operacional. Na prtica, as mquinas virtuais nestacategoria so desenvolvidas para computadores fictcios projetados para uma fina-lidade especfica. A camada exporta uma abstrao para a execuo de programas

escritos para esta virtualizao. Java JVM e Smalltalk so exemplos deste tipo demquina virtual.

O trabalho [Nanda and Chiueh 2005] ainda classifica a virtualizao como:

Abstrao da ISA (Instruction Set Architecture): a virtualizao implementadacom o uso da emulao completa da ISA. O emulador executa as instrues dosistema convidado (a mquina virtual obtida por meio da emulao) utilizando atraduo das instrues para o sistema nativo. Esta arquitetura robusta e simplespara implementao, mas a perda de desempenho significativa. Bochs, Crusoe e

QEMU so exemplos da mesma. Hardware Abstraction Layer(HAL): o hipervisor simula uma arquitetura completa

para o sistema convidado. Desta forma, o sistema convidado acredita estar execu-tando sobre um sistema completo de hardware. VMware, Virtual PC, Denali e Xenso exemplos desta arquitetura.

OS Level (sistema operacional): este nvel de virtualizao obtido utilizando umachamada de sistema (system call) especfica. O principal benefcio da virtualizaoneste nvel criar uma camada para obter o isolamento de processos, cada sistema virtualizado com seu prprio endereo IP e outros recursos de hardware (embora

limitados). A virtualizao ocorre a partir de um diretrio ou sistema de arquivosseparadado e previamente preparado para este fim. O FreeBSD Jail um exemplodesta arquitetura.


15/49

Nvel de aplicao ou virtualizao de linguagens de programao: a virtualiza-o obtida por meio da abstrao de uma camada de execuo. Uma aplicao

utiliza esta camada para executar as instrues do programa. Esta soluo garanteque uma aplicao possa ser executada em qualquer plataforma de software ouhardware, pois a camada abstrada de forma idntica em todas as plataformas.Todavia, torna-se necessria uma mquina virtual especfica para cada plataforma.

Java JVM, Microsoft .NET CLI e Parrot so exemplos desta arquitetura.

User level library interface (biblioteca de interface para usurio): vrios sistemase aplicaes so escritos utilizando um conjunto de APIs fornecidos pelo sistema(aplicaes sob o sistema Windows so os exemplos mais populares), exportadospara o nvel do usurio por meio de bibliotecas. A virtualizao neste nvel obtidacom a abstrao do topo do sistema operacional, para que as aplicaes possam

executar em outra plataforma. O Wine um exemplo deste tipo de arquitetura.

4.1.4.1. Mquinas Virtuais de Aplicao

Uma mquina virtual de aplicao (ou Process Virtual Machine) suporta a execuo deum processo ou aplicao individual. Ela criada sob demanda, no momento do lana-mento da aplicao convidada, e destruda quando a aplicao finaliza sua execuo. Oconjunto hipervisor + aplicao visto ento como um nico processo dentro do sis-tema operacional subjacente, submetido s mesmas condies e restries que os demaisprocessos nativos.

Os hipervisores que implementam mquinas virtuais de aplicao normalmentepermitem a interao entre a aplicao convidada e as demais aplicaes do sistema, atra-vs dos mecanismos usuais de comunicao e coordenao entre processos, como men-sagens, pipes e semforos. Alm disso, tambm permitem o acesso normal ao sistema dearquivos e outros recursos locais do sistema. Ao criar a mquina virtual para uma apli-cao, o hipervisor pode implementar a mesma interface de hardware (ISA) da mquinareal subjacente, ou implementar uma interface distinta. Quando a interface da mquinareal preservada, boa parte das instrues do processo convidado podem ser executadasdiretamente, com exceo das instrues sensveis, que devem ser interpretadas pelo hi-pervisor. Os exemplos mais comuns de mquinas virtuais de aplicao que preservam ainterface ISA real so os sistemas operacionais multi-tarefas, os tradutores dinmicos ealguns depuradores de memria:

Sistemas operacionais multi-tarefas: os sistemas operacionais que suportam vriosprocessos simultneos tambm podem ser vistos como ambientes de mquinas vir-tuais. Em um sistema multi-tarefas, cada processo recebe um processador virtual(simulado atravs de fatias de tempo do processador real), uma memria virtual(atravs do espao de endereos mapeado para aquele processo) e recursos fsicos(acessveis atravs de chamadas de sistema). Este ambiente de mquinas virtu-ais to antigo e to presente em nosso cotidiano que costumamos ignor-lo. Noentanto, ele simplifica muito a tarefa dos programadores, que no precisam se pre-ocupar com a gesto do compartilhamento desses recursos entre os processos.


16/49

Tradutores dinmicos: um tradutor dinmico consiste em um hipervisor que analisae otimiza um cdigo executvel, para tornar sua execuo mais rpida e eficiente. A

otimizao no muda o conjunto de instrues da mquina real usado pelo cdigo,apenas reorganiza as instrues de forma a acelerar sua execuo. Por ser dinmica,a otimizao do cdigo feita durante a carga do processo na memria ou durantea execuo de suas instrues, de forma transparente. O artigo [Duesterwald 2005]apresenta uma descrio detalhada desse tipo de abordagem.

Depuradores de memria: alguns sistemas de depurao de erros de acesso me-mria, como o sistema Valgrind [Seward and Nethercote 2005], executam o pro-cesso sob depurao em uma mquina virtual. Todas as instrues do programaque manipulam acessos memria so executadas de forma controlada, a fim de en-contrar possveis erros. Ao depurar um programa, o sistema Valgrind inicialmente

traduz seu cdigo em um conjunto de instrues interno, manipula esse cdigo parainserir operaes de verificao de acessos memria e traduz o cdigo modificadode volta ao conjunto de instrues da mquina real, para em seguida execut-lo everificar os acessos memria realizados.

As mquinas virtuais de aplicao mais populares hoje so aquelas em que a in-terface binria de aplicao (ABI) requerida pela aplicao diferente da oferecida pelamquina real. Como a ABI composta pelas chamadas do sistema operacional e as ins-trues de mquina disponveis aplicao (user ISA), as diferenas podem ocorrer emambos. Nos dois casos, o hipervisor ter de realizar tradues dinmicas (durante a exe-

cuo) das aes requeridas pela aplicao em suas equivalentes na mquina real (comovisto, um hipervisor com essa funo denominado tradutor dinmico).

Caso as diferenas de interface entre aplicao e mquina real se restrinjam schamadas do sistema operacional, o hipervisor precisa apenas mapear as chamadas desistema usadas pela aplicao sobre as chamadas oferecidas pelo sistema operacional damquina real. Essa a abordagem usada, por exemplo, pelo ambiente Wine, que permiteexecutar aplicaes Windows em plataformas Unix. As chamadas de sistema Windowsemitidas pela aplicao em execuo so interceptadas e transformadas em chamadasUnix, de forma dinmica e transparente (figura 4.12).

Entretanto, muitas vezes a interface ISA utilizada pela aplicao no correspondea nenhum hardware existente, mas a um hardware simplificado que representa uma m-quina abstrata. Um exemplo tpico dessa situao ocorre na linguagem Java: um pro-grama escrito em Java, ao ser compilado, gera um cdigo binrio especfico para umamquina abstrata denominada mquina virtual Java ( JVM Java Virtual Machine). Alinguagem de mquina executada pela mquina virtual Java denominada bytecode Java,e no corresponde a instrues de nenhum processador real. A mquina virtual deve en-to interpretar todas as operaes do bytecode, utilizando as instrues da mquina realsubjacente para execut-las.

A vantagem mais significativa da abordagem adotada por Java a portabilidade

do cdigo executvel: para que uma aplicao Java possa executar sobre uma determinadaplataforma, basta que a mquina virtual Java esteja disponvel ali (na forma de um suportede execuo denominado JRE Java Runtime Environment). Assim, a portabilidade dos


17/49

Figura 4.12. Funcionamento do emulador Wine.

programas Java depende unicamente da portabilidade da prpria mquina virtual Java. Osuporte de execuo Java pode estar associado a um navegador Web, o que permite que ocdigo Java seja associado a pginas Web, na forma de pequenas aplicaes denominadasapplets, que so trazidas junto com os demais componentes de pgina Web e executamlocalmente no navegador1.

Em termos de desempenho, um programa compilado para uma mquina virtualexecuta mais lentamente que seu equivalente compilado sobre uma mquina real, devidoao custo de interpretao do bytecode. Todavia, essa abordagem oferece melhor desem-penho que linguagens puramente interpretadas. Alm disso, tcnicas de otimizao comoa compilao Just-in-Time (JIT), na qual blocos de instrues repetidos freqentementeso compilados pelo hipervisor e armazenados em cache, permitem obter ganhos de de-sempenho significativos em aplicaes executando sobre mquinas virtuais.

4.1.4.2. Mquinas Virtuais de Sistema

Uma mquina virtual de sistema suporta um ou mais sistemas operacionais convidados,com suas respectivas aplicaes, que executam de forma isolada e independente. Cada

sistema operacional convidado tem a iluso de executar sozinho sobre uma plataforma dehardware prpria.

Em um ambiente virtual, os sistemas operacionais convidados so fortemente iso-lados uns dos outros, e normalmente s podem interagir atravs dos mecanismos de rede,como se estivessem em mquinas fisicamente separadas. Todavia, alguns sistemas de m-quinas virtuais permitem o compartilhamento controlado de certos recursos. Por exemplo,os sistemas VMware Workstation e VirtualBox permitem a definio de diretrios com-partilhados no sistema de arquivos real, que podem ser acessados pelas mquinas virtuais.

1Neste caso, a propriedade de isolamento das mquinas virtuais aplicada aos applets Java, para evitarque cdigos maliciosos trazidos da Internet executem aes prejudiciais no sistema local; este mecanismo

conhecido como Java Sandbox.


18/49

O hipervisor de sistema fornece aos sistemas operacionais convidados uma inter-face de sistema ISA virtual, que pode ser idntica ao hardware real, ou distinta. Alm

disso, ele virtualiza o acesso aos recursos, para que cada sistema operacional convidadotenha um conjunto de recursos virtuais prprio, construdo a partir dos recursos fsicosexistentes na mquina real. Assim, cada mquina virtual ter sua prpria interface derede, seu prprio disco, sua prpria memria RAM, etc.

As mquinas virtuais de sistema constituem a primeira abordagem usada para aconstruo de hipervisores, desenvolvida na dcada de 1960 e formalizada por Popek eGoldberg [Popek and Goldberg 1974]. Naquela poca, a tendncia de desenvolvimentode sistemas computacionais buscava fornecer a cada usurio uma mquina virtual comseus recursos virtuais prprios, sobre a qual o usurio executava um sistema operacionalmono-tarefa e suas aplicaes. Assim, o compartilhamento de recursos no era respon-

sabilidade do sistema operacional convidado, mas do hipervisor subjacente. No entanto,ao longo dos anos 70, como o desenvolvimento de sistemas operacionais multi-tarefaseficientes e seguros como MULTICS e UNIX, as mquinas virtuais de sistema perderamgradativamente seu interesse. Somente no final dos anos 90, com o aumento do poderde processamento dos micro-processadores e o surgimento de novas possibilidades deaplicao, as mquinas virtuais de sistema foram redescobertas.

Existem vrios tipos de ambientes de mquinas virtuais de sistema, que podem serclassificados quanto sua arquitetura e quanto ao grau de virtualizao do hardware. Noque diz respeito arquitetura, existem basicamente dois tipos de hipervisores de sistema,apresentados na figura 4.13:

Hipervisores nativos (ou de tipo I): nesta categoria, o hipervisor executa direta-mente sobre o hardware da mquina real, sem um sistema operacional subjacente.A funo do hipervisor multiplexar os recursos de hardware (memria, discos,interfaces de rede, etc) de forma que cada mquina virtual veja um conjunto de re-cursos prprio e independente. Assim, cada mquina virtual se comporta como umamquina fsica completa que pode executar o seu prprio sistema operacional. Esta a forma mais antiga de virtualizao, encontrada nos sistemas computacionais degrande porte dos anos 1960-70. Alguns exemplos de sistemas que empregam estaabordagem so o IBM OS/370, o VMware ESX Servere o ambiente Xen.

Hipervisores convidados (ou de tipo II): nesta categoria, o hipervisor executa comoum processo normal sobre um sistema operacional nativo subjacente. O hipervisorutiliza os recursos oferecidos pelo sistema operacional nativo para oferecer recursosvirtuais ao sistema operacional convidado que executa sobre ele. Normalmente,um hipervisor convidado suporta apenas uma mquina virtual com uma instnciade sistema operacional convidado. Caso mais mquinas sejam necessrias, maishipervisores devem ser lanados. Exemplos de sistemas que adotam esta estruturaincluem o VMware Workstation, o QEMU e o VirtualBox.

Pode-se afirmar que os hipervisores convidados so mais flexveis que os hipervi-sores nativos, pois podem ser facilmente instalados/removidos em mquinas com sistemas


19/49

Figura 4.13. Arquiteturas de mquinas virtuais de sistema.

operacionais previamente instalados. Por outro lado, um hipervisor nativo tem melhor de-sempenho que um hipervisor convidado, pois este ltimo tem de usar os recursos ofereci-dos pelo sistema operacional subjacente, enquanto o primeiro pode acessar diretamente ohardware real.

No que diz respeito ao nvel de virtualizao oferecido pelo hipervisor, os ambi-entes de mquinas virtuais podem ser classificados em duas categorias, conforme apre-sentado na figura 4.14:

Virtualizao de recursos: nesta categoria, a interface ISA de usurio mantida,apenas as instrues privilegiadas e os recursos (discos, etc) so virtualizados.Dessa forma, o sistema operacional convidado e as aplicaes convidadas vemo processador real. Como as quantidades de instrues a virtualizar so pequenas,o desempenho do sistema convidado prximo daquele obtido, se ele estivesseexecutando diretamente sobre o hardware real. Os sistemas VMware Workstation,VirtualBox e MS VirtualPC implementam esta estratgia.

Virtualizao completa: nesta categoria, toda a interface do hardware virtuali-zada, incluindo todas as instrues do processador e os dispositivos de hardware.

Isso permite oferecer ao sistema operacional convidado uma interface de hardwaredistinta daquela fornecida pela mquina real subjacente. O custo de virtualizaoneste caso bem maior que na virtualizao parcial (de recursos), mas esta aborda-gem permite executar sistemas operacionais em plataformas distintas daquela paraa qual foram inicialmente projetados. Exemplos tpicos desta abordagem so ossistemas de mquinas virtuais QEMU, que oferece um processador Intel Pentium

II ao sistema convidado, o MS VirtualPC for MAC, que permite executar o sistemaWindows sobre uma plataforma de hardware PowerPC, e o sistema Hercules, queemula um computador IBM System/390 sobre um PC convencional de plataformaIntel.

Uma categoria especial de hipervisor nativo com virtualizao completa consistenos hipervisores embutidos no hardware (codesigned hypervisors). Um hipervisor em-


20/49

Figura 4.14. Nveis de virtualizao: virtualizao de recursos e virtualizao completa.

butido visto como parte integrante do hardware da mquina real, e implementa a inter-face de sistema (ISA) vista pelos sistemas operacionais e aplicaes daquela plataforma.O conjunto de instrues do processador real somente est acessvel ao hipervisor, quereside em uma rea de memria separada da memria principal e usa tcnicas de tradu-o dinmica para executar as instrues dos sistemas convidados. Um exemplo tpicodesse tipo de sistema o processador Transmeta Crusoe/Efficeon, que aceita instruesno padro Intel 32 bits e internamente as converte em um conjunto de instrues VLIW(Very Large Instruction Word). Como o hipervisor desse processador pode ser reprogra-

mado para criar novas instrues ou modificar as instrues existentes, ele acabou sendodenominado Code Morphing Software (figura 4.15).

Figura 4.15. Hipervisor embutido no hardware.

A figura 4.16 traz uma classificao dos tipos de mquinas virtuais de sistema, deacordo com os critrios de arquitetura do hipervisor e grau de virtualizao oferecido aossistemas convidados.


21/49

Figura 4.16. Classificao de mquinas virtuais de sistema.

4.1.5. Estratgias de Virtualizao

A construo de hipervisores implica na definio de algumas estratgias para a virtua-lizao. As estratgias mais utilizadas atualmente so a virtualizao total ( full virtuali-

zation), normalmente associada traduo dinmica (dynamic translation), e a paravirtu-alizao (paravirtualization). Alm disso, algumas tcnicas complementares so usadaspara melhorar o desempenho dos sistemas de mquinas virtuais. Essas tcnicas so dis-cutidas nesta seo.

4.1.5.1. Virtualizao Total

A virtualizao total reconstri um ambiente virtual no qual o hardware fornecido aossistemas convidados corresponde a um sistema real existente, Toda a interface de acesso

ao hardware virtualizada, incluindo todas as instrues do processador e os dispositivosde hardware. Desta forma, os sistemas convidados no precisam sofrer nenhum tipo dealterao ou ajuste para executar no ambiente virtual. Esta a abordagem usada na mai-


22/49

oria dos hipervisores de sistema clssicos, como QEmu e VMWare. Sua maior vantagemconsiste em permitir que sistemas operacionais convencionais executem como convida-

dos sem necessidade de modificaes. Por outro lado, o sistema convidado executa maislentamente, uma vez que todos os acessos ao hardware so intermediados pelo hipervisor.Alm disso, o hipervisor ter de interceptar e emular todas as instrues sensveis execu-tadas pelos sistemas convidados, o que tem um custo elevado em plataformas de hardwaresem suporte adequado virtualizao.

4.1.5.2. Traduo dinmica

Uma tcnica freqentemente utilizada na construo de mquinas virtuais a traduodinmica (dynamic translation) ou recompilao dinmica (dynamic recompilation) de

partes do cdigo binrio dos sistemas convidados e suas aplicaes. Nesta tcnica, ohipervisor analisa, reorganiza e traduz as seqncias de instrues emitidas pelo sistemaconvidado em novas seqncias de instrues, medida em que a execuo do sistemaconvidado avana.

A traduo binria dinmica pode ter vrios objetivos: (a) adaptar as instruesgeradas pelo sistema convidado interface ISA do sistema real, caso no sejam idnticas;(b) detectar e tratar instrues sensveis no-privilegiadas (que no geram interrupesao serem invocadas pelo sistema convidado); ou (c) analisar, reorganizar e otimizar asseqncias de instrues geradas pelo sistema convidado, de forma a melhorar o desem-penho de sua execuo. Neste ltimo caso, os blocos de instrues muito freqentes

podem ter suas tradues mantidas em cache, para melhorar ainda mais o desempenho.A traduo dinmica usada em vrios tipos de hipervisores. Uma aplicao

tpica a construo da mquina virtual Java, onde recebe o nome de JIT Just-in-TimeBytecode Compiler. Outro uso corrente a construo de hipervisores para plataformassem suporte adequado virtualizao, como os processadores Intel/AMD 32 bits. Nestecaso, o cdigo convidado a ser executado analisado em busca de instrues sensveis,que so substitudas por chamadas a rotinas apropriadas dentro do supervisor.

No contexto de virtualizao, a recompilao dinmica composta basicamentedos seguintes passos [Ung and Cifuentes 2006]:

1. Desmontagem (disassembling): o fluxo de bytes do cdigo convidado a executar decomposto em blocos de instrues. Cada bloco normalmente composto deuma seqncia de instrues de tamanho varivel, terminando com uma instruode controle de fluxo de execuo;

2. Gerao de cdigo intermedirio: cada bloco de instrues tem sua semntica des-crita atravs de uma representao independente de mquina;

3. Otimizao: a descrio em alto nvel do bloco de instrues analisada para apli-car eventuais otimizaes; como este processo realizado durante a execuo, nor-malmente somente otimizaes com baixo custo computacional so aplicveis;

4. Codificao: o bloco de instrues otimizado traduzido para instrues da m-quina fsica, que podem ser diferentes das instrues do cdigo original;


23/49

5. Caching: blocos de instrues com execuo muito freqente tm sua traduoarmazenada em cache, para evitar ter de traduzi-los e otimiz-los novamente;

6. Execuo: o bloco de instrues traduzido finalmente executado nativamente peloprocessador da mquina real.

Esse processo pode ser simplificado caso as instrues de mquina do cdigo con-vidado sejam as mesmas da mquina real subjacente, o que torna desnecessrio traduziros blocos de instrues em uma representao independente de mquina.

4.1.5.3. Paravirtualizao

Em meados dos anos 2000, alguns pesquisadores investigaram a possibilidade de mo-dificar a interface entre o hipervisor e os sistemas convidados, oferecendo a estes umhardware virtual que similar, mas no idntico ao hardware real. Essa abordagem,denominada paravirtualizao, permite um melhor acoplamento entre os sistemas convi-dados e o hipervisor, o que leva a um desempenho significativamente melhor das mqui-nas virtuais. As modificaes na interface de sistema do hardware virtual (system ISA)exigem uma adaptao dos sistemas operacionais convidados, para que estes possam exe-cutar sobre a plataforma virtual. Todavia, a interface de usurio (user ISA) do hardware preservada, permitindo que as aplicaes convidadas executem sem necessidade de mo-dificaes. Esse conceito ilustrado na figura 4.17, adaptada [Ferre et al. 2006].

Figura 4.17. Relao entre a virtualizao total e a paravirtualizao.

Os primeiros ambientes a adotar a paravirtualizao foram o Denali[Whitaker et al. 2002] e o Xen [Barham et al. 2003]. O Denali um ambiente experi-mental de paravirtualizao construdo na Universidade de Washington, que pode supor-tar dezenas de milhares de mquinas virtuais sobre um computador x86 convencional.


24/49

O projeto Denali no se preocupa em suportar sistemas operacionais comerciais, sendovoltado execuo macia de minsculas mquinas virtuais para servios de rede. J o

ambiente de mquinas virtuais Xen, apresentado com mais detalhes na seo 4.3.3, per-mite executar sistemas operacionais convencionais como Linux e Windows, modificadospara executar sobre seu hipervisor.

Embora exija que o sistema convidado seja adaptado ao hipervisor, o que diminuisua portabilidade, a paravirtualizao permite que o sistema convidado acesse alguns re-cursos do hardware diretamente, sem a intermediao ativa do hipervisor. Nesses casos,o acesso ao hardware apenas monitorado pelo hipervisor, que informa ao sistema convi-dado seus limites, como as reas de memria e de disco disponveis. O acesso aos demaisdispositivos, como mouse e teclado, tambm direto: o hipervisor apenas gerencia aordem de acessos, no caso de mltiplos sistemas convidados em execuo simultnea.

A diferena entre a virtualizao total e a paravirtualizao pode ser melhor com-preendida observando-se a virtualizao do acesso memria. Na virtualizao total, ohipervisor reserva um espao de memria separado para cada sistema convidado; no en-tanto, todos os sistemas convidados vem suas respectivas reas de memria iniciandono endereo 0000H. A figura 4.18 ilustra essa situao. Dessa forma, cada vez que umsistema convidado acessa a memria, o hipervisor traduz os endereos gerados por elepara as posies reais da rea de memria daquele sistema convidado. Por outro lado, naparavirtualizao, o hipervisor informa ao sistema operacional convidado as reas de me-mria que este pode utilizar. Dessa forma, o sistema convidado pode acessar e gerenciardiretamente a memria reservada a ele, sem a interferncia direta do hipervisor.

Figura 4.18. Viso da memria por um sistema convidado.

Apesar de exigir modificaes nos sistemas operacionais convidados, a paravir-tualizao tem tido sucesso, por conta do desempenho obtido nos sistemas virtualizados,alm de simplificar a interface de baixo nvel dos sistemas convidados.


25/49

4.1.5.4. Melhoria de desempenho

De acordo com os princpios de Goldberg e Popek, o hipervisor deve permitir que a m-quina virtual execute diretamente sobre o hardware sempre que possvel, para no pre-judicar o desempenho dos sistemas convidados. O hipervisor deve retomar o controledo processador somente quando a mquina virtual tentar executar operaes que possamafetar o correto funcionamento do sistema, o conjunto de operaes de outras mqui-nas virtuais ou do prprio hardware. O hipervisor deve ento simular com segurana aoperao solicitada e devolver o controle mquina virtual.

Na prtica, os hipervisores nativos e convidados raramente so usados em suaforma conceitual. Vrias otimizaes so inseridas nas arquiteturas apresentadas, como objetivo principal de melhorar o desempenho das aplicaes nos sistemas convidados.

Como os pontos cruciais do desempenho dos sistemas de mquinas virtuais so as opera-es de entrada/sada, as principais otimizaes utilizadas em sistemas de produo dizemrespeito a essas operaes. Quatro formas de otimizao so usuais:

Em hipervisores nativos (figura 4.19):

1. O sistema convidado (guest system) acessa diretamente o hardware. Essaforma de acesso implementada por modificaes no ncleo do sistema con-vidado e no hipervisor. Essa otimizao implementada, por exemplo, nosubsistema de gerncia de memria do ambiente Xen [Barham et al. 2003].

Em hipervisores convidados (figura 4.19):

1. O sistema convidado (guest system) acessa diretamente o sistema nativo (hostsystem). Essa otimizao implementada pelo hipervisor, oferecendo partesda API do sistema nativo ao sistema convidado. Um exemplo dessa otimiza-o a implementao do sistema de arquivos no VMware [VMware 2000]:em vez de reconstruir integralmente o sistema de arquivos sobre um dispo-sitivo virtual provido pelo hipervisor, o sistema convidado faz uso da imple-mentao de sistema de arquivos existente no sistema nativo.

2. O sistema convidado (guest system) acessa diretamente o hardware. Essa oti-mizao implementada parcialmente pelo hipervisor e parcialmente pelo sis-tema nativo, pelo uso de um device driver especfico. Um exemplo tpicodessa otimizao o acesso direto a dispositivos fsicos como leitor de CDs,hardware grfico e interface de rede provida pelo sistema VMware aos siste-mas operacionais convidados [VMware 2000].

3. O hipervisor acessa diretamente o hardware. Neste caso, um device driveres-pecfico instalado no sistema nativo, oferecendo ao hipervisor uma interfacede baixo nvel para acesso ao hardware subjacente. Essa abordagem, ilustradana figura 4.20, usada pelo sistema VMware [VMware 2000].


26/49

Figura 4.19. Otimizaes em sistemas de mquinas virtuais.

Figura 4.20. Desempenho de hipervisores nativos e convidados.

4.2. Virtualizao e segurana

A evoluo da tecnologia de mquinas virtuais tem permitido sua ampla adoo emsistemas de produo. Vrios aspectos da construo de hipervisores, em sua maioriarelacionados com o desempenho de execuo dos sistemas convidados, foram resolvi-dos nos ltimos anos [Rosenblum and Garfinkel 2005]. Atualmente, a principal utiliza-o de mquinas virtuais no meio corporativo tem sido a consolidao de servidores,buscando a reduo de custos em hardware, software e gerncia do parque tecnolgico[Newman et al. 2005, Ferre et al. 2006]. No entanto, vrios trabalhos de pesquisa e de-senvolvimento nos ltimos anos comprovaram a eficcia da utilizao de mquinas vir-


27/49

tuais no campo da segurana de sistemas. Esta seo discute como as propriedades doshipervisores (apresentadas na seo 4.1.3.2) podem ser aplicadas na segurana de siste-

mas e discute alguns usos tpicos de mquinas virtuais nesse contexto.4.2.1. Aplicaes da virtualizao em segurana

Conforme [Krause and Tipton 1999], so trs os princpios bsicos para garantir a segu-rana da informao:

Confidencialidade: a informao somente est visvel a sujeitos (usurios e/ou pro-cessos) explicitamente autorizados;

Disponibilidade: a informao deve estar prontamente disponvel sempre que fornecessria;

Integridade: a informao somente pode ser modificada por sujeitos explicitamenteautorizados e de formas claramente definidas.

Alm destes, outros critrios devem ser respeitados para um sistema ser conside-rado seguro [Smola 2003]:

Autenticidade: garante que a informao ou o usurio da mesma autntico, ouseja, garante que a entidade envolvida quem afirma ser;

No-repdio: no possvel negar a existncia ou autoria de uma operao quecriou, modificou ou destruiu uma informao;

Auditoria: implica no registro das aes realizadas no sistema, identificando os su-jeitos e recursos envolvidos, as operaes realizadas, seus horrios, locais e outrosdados relevantes.

Algumas das propriedades conceituais da virtualizao discutidas na seo 4.1.3.2podem ser teis para o atendimento desses critrios de segurana:

Isolamento: ao manter os ambientes virtuais isolados entre si e do sistema real sub-jacente, o hipervisor prov a confidencialidade de dados entre os sistemas convida-dos. Adicionalmente, como os dados presentes em uma mquina virtual s podemser acessados pelas respectivas aplicaes convidadas, sua integridade preservada.Alm disso, o isolamento permite a conteno de erros de software acidentais ouintencionais no mbito da mquina virtual [LeVasseur et al. 2004, Tan et al. 2007],o que permite melhorar a disponibilidade dos sistemas;

Controle de recursos: Como o hipervisor intermedeia os acessos do sistema convi-dado ao hardware, possvel implementar mecanismos para verificar a consistncia

desses acessos e de seus resultados, aumentando a integridade do sistema convi-dado; da mesma forma, possvel acompanhar e registrar as atividades do sistemaconvidado, para fins de auditoria [Dunlap et al. 2002];


28/49

Inspeo: a viso privilegiada do hipervisor sobre o estado interno do sistema con-vidado permite extrair informaes deste para o sistema hospedeiro, permitindo

implementar externamente mecanismos de verificao de integridade do ambienteconvidado, como antivrus e detectores de intruso [Laureano et al. 2007]; almdisso, a capacidade de inspeo do sistema convidado, aliada ao isolamento pro-vido pelo hipervisor, torna as mquinas virtuais excelentes bales de ensaio parao estudo de aplicaes maliciosas como vrus e trojans;

Encapsulamento: a possibilidade de salvar/restaurar o estado do sistema convidadotorna vivel a implementao de mecanismos de rollback teis no caso de quebrada integridade do sistema convidado; da mesma forma, a migrao de mquinasvirtuais uma soluo vivel para o problema da disponibilidade [Fu and Xu 2005];

Nos ltimos anos, muitos projetos de pesquisa estudaram a aplicao das proprie-dades das mquinas virtuais na construo de sistemas computacionais seguros e confi-veis. Algumas dessas pesquisas visam proteger e aumentar a disponibilidade de sistemase servios, outras visam estudar o comportamento de aplicaes maliciosas, mas tam-bm h estudos visando criar aplicaes maliciosas que tirem proveito da virtualizao,ao menos como prova de conceito. Esses trabalhos abordam diversas aplicaes, comoo confinamento de servios, a deteco de intruso, a anlise de malwares, a construode honeypots e rootkits, tcnicas de contingenciamento e de tolerncia a falhas. Algumasdessas pesquisas sero discutidas nas prximas sees.

4.2.2. Confinamento de aplicaes

Em um sistema operacional, cada processo tem acesso a um conjunto de recursos parafuncionar. Esse conjunto definido atravs de regras de controle de acesso impostas peloncleo do sistema. Alm disso, a lgica interna do processo tambm pode limitar os re-cursos acessveis a seu respectivo usurio. Por exemplo, um servidor Web pode acessar osarquivos autorizados pelas permisses do sistema de arquivos, mas tambm possui regrasinternas para limitar os arquivos e diretrios acessveis aos clientes. Todavia, serviosmal configurados, erros nas regras de controle de acesso, vulnerabilidades no servio ouno sistema operacional podem expor informaes indevidamente, comprometendo a con-fidencialidade e integridade do sistema. Esse problema pode ser atenuado de diversasformas:

Monitorar a aplicao usando IDS, antivrus etc. Esta soluo pode requerer umtrabalho de configurao significativo; alm disso, essas ferramentas tambm soprocessos, consumindo recursos e sendo passveis de falhas ou subverso;

Designar um equipamento separado para a aplicao sensvel executar isolada-mente, o que pode custar caro;

Colocar a aplicao para executar dentro de uma mquina virtual, isolando-a dorestante do sistema hospedeiro.

Em princpio, qualquer hipervisor convencional pode ser usado para confinar umaaplicao. Todavia, neste caso especfico, a principal motivao para o uso de mqui-nas virtuais a propriedade de isolamento (seo 4.1.3.2). Como essa propriedade no


29/49

implica necessariamente a virtualizao do processador ou dos demais recursos de hard-ware, tcnicas simplificadas e com baixo custo computacional foram concebidas para

implement-la. Essas tcnicas so conhecidas como servidores virtuais.Em um servidor virtual, a interface binria (ABI), composta pelas chamadas de

sistema e instrues do processador, totalmente preservada. O espao de usurio dosistema operacional dividido em reas isoladas denominadas domnios virtuais. Cadadomnio virtual recebe uma parcela dos recursos do sistema, como memria, tempo deprocessador e espao em disco. Alguns recursos do sistema real podem ser virtualizados,como as interfaces de rede: cada domnio tem sua prpria interface virtual e seu prprioendereo de rede. Em algumas implementaes, cada domnio virtual pode impor seuprprio espao de nomes: assim, pode-se ter um usurio pedro no domnio d3 e outrousurio pedro no domnio d7, sem conflitos. A distino de espaos de nomes pode se

estender a outros recursos do sistema: identificadores de processos, semforos, rvoresde diretrios, etc.

Os processos confinados em um determinado domnio podem interagir entre si,criar novos processos e usar os recursos presentes naquele domnio, respeitando as regrasde controle de acesso associadas a esses recursos. Todavia, processos em um domnio nopodem interagir com processos em outro domnio, no podem mudar de domnio, criarprocessos em outros domnios, nem usar recursos de outros domnios. Para cada domnio,os demais domnios so mquinas distintas. Normalmente definido um domnio d0, oudomnio de gerncia, cujos processos tm acesso aos demais domnios. A figura 4.21mostra a estrutura tpica de um sistema de servidores virtuais. Nela, pode-se observar que

um processo pode migrar de d0 para d1, mas que processos em d1 no podem migrar paraoutros domnios. A comunicao entre processos confinados em domnios distintos (d2 ed3) tambm proibida.

Figura 4.21. Servidores virtuais.

H vrias implementaes disponveis de mecanismos de confinamento de pro-cessos. A tcnica mais antiga realizada atravs da chamada de sistema chroot. OSistema FreeBSD implementa o ambiente Jails [Kamp and Watson 2000] para este fim.Existem implementaes similares em outros sistemas operacionais, como as Zones do

sistema Solaris e os sistemas Virtuozzo/OpenVZ e Vservers/FreeVPS, para Linux.


30/49

4.2.3. Deteco de intruso

Sistemas de deteco de intruso (IDS Intrusion Detection Systems) tm como funo

monitorar uma rede ou sistema computacional, buscando detectar ataques ou atividadesmaliciosas. Esses sistemas continuamente coletam dados do sistema e os analisam atravsde tcnicas diversas, como reconhecimento de padres, anlise estatstica e minerao dedados. Ao detectar uma atividade maliciosa, podem alertar o administrador do sistemae/ou ativar contra-medidas. De acordo com a origem da informao analisada, os IDSspodem ser classificados como:

IDSs de mquina (HIDS Host-based IDS): monitoram um computador para iden-tificar atividades maliciosas locais, como subverso de servios, vrus e trojans.

IDSs de rede (NIDS Network-based IDS): monitoram o trfego de uma rede, paraidentificar ataques aos computadores a ela conectados.

Sistemas NIDS monitoram vrios computadores simultaneamente, mas sua efic-cia diminui na medida em que o trfego da rede aumenta, pela necessidade de analisarpacotes mais rapidamente. Alm disso, o uso de protocolos de rede cifrados torna o con-tedo dos pacotes opaco ao NIDS. Sistemas HIDS no sofrem desses problemas, poisanalisam as informaes disponveis dentro de cada sistema. Todavia, um HIDS umprocesso local, que pode ser desativado ou subvertido por um ataque bem-sucedido.

As mquinas virtuais podem ser teis na proteo de sistemas HIDS. Atravs da

propriedade de inspeo, o hipervisor pode extrair informaes de um sistema convidadoe encaminh-las para anlise por um detector de intruso executando no sistema nativo,ou em outra mquina virtual. O isolamento entre mquinas virtuais assegura a integridadedas informaes coletadas e do prprio detector de intruso. Por fim, a propriedade decontrole de recursos permite ao hipervisor intervir no sistema convidado, para interromperatividades consideradas suspeitas pelo detector de intruso.

No sistema ReVirt[Dunlap et al. 2002], uma camada construda entre o hipervisore o sistema hospedeiro recebe as mensagens de syslog2 geradas no sistema convidadoe as registra no sistema hospedeiro. Essas mensagens so ento usadas para detectarerros ou atividades maliciosas envolvendo os servios do sistema convidado. Alm disso,

a camada ReVirt realiza checkpoints regulares do sistema convidado, que a permitemreverter o sistema a um estado anterior seguro, no caso de um ataque bem sucedido.

O trabalho [Garfinkel and Rosenblum 2003] descreve uma arquitetura para a de-teco de intruso em mquinas virtuais denominada VMI IDS (Virtual Machine Intros-

pection Intrusion Detection System). Sua abordagem considera o uso de um hipervisornativo, executando diretamente sobre o hardware. O IDS executa em uma das mquinasvirtuais e observa dados obtidos das demais mquinas virtuais, buscando evidncias deintruso. Somente o estado global da mquina virtual (registradores, consumo de mem-ria, etc) analisado, sem levar em conta as atividades dos processos nela contidos, ouseja, o sistema proposto no tem a capacidade de avaliar processos individuais. Por isso,

sua capacidade de resposta limitada: caso haja suspeita de intruso, a mquina virtual2Daemon UNIX que registra as mensagens de log geradas pelas aplicaes em execuo no sistema.


31/49

comprometida suspensa at que essa suspeita seja confirmada; nesse caso, a mesmapode ser reiniciada ou revertida a um estado anterior seguro (rollback).

Por outro lado, o trabalho [Laureano et al. 2004, Laureano et al. 2007] utiliza umhipervisor convidado modificado, que extrai informaes do sistema convidado e as sub-mete a um detector de intruso executando no sistema hospedeiro. A deteco de in-truso baseada nas seqncias de chamadas de sistema emitidas pelos processos dosistema convidado; dessa forma, cada processo convidado pode ser analisado separada-mente. Caso o comportamento de um processo seja considerado anmalo, o hipervisorgera um alerta de suspeita e restringe as chamadas de sistema disponveis ao processo.

4.2.4. Anlise de programas maliciosos

[Klaus 1999, Skoudis and Zeltser 2003] consideram a existncia de dois tipos de progra-

mas prejudiciais (figura 4.22):

Intencionais: programas escritos para se infiltrar em um sistema, sem conhecimentode seus usurios, com a inteno de causar dano, furto ou seqestro de informaes.Esses programas so conhecidos como malwares (de malicious softwares);

No-intencionais: programas normais contendo erros de programao ou de con-figurao que permitam a manipulao no-autorizada das informaes de um sis-tema; esses erros de programao ou de configurao so denominados vulnerabi-lidades.

Figura 4.22. Classificao dos Programas Prejudiciais [Klaus 1999].

Para [Skoudis and Zeltser 2003], os malwares so conjuntos de instrues execu-tadas em um computador e que fazem o sistema realizar algo que um atacante deseja. Deforma geral, os malwares podem ser classificados em:

Vrus: classe de software malicioso com a habilidade de se auto-replicar e infectarpartes do sistema operacional ou dos programas de aplicao, visando causar aperda ou danos nos dados;

Worm: designa qualquer software capaz de propagar a si prprio em uma rede. Ha-bitualmente os worms invadem os sistemas computacionais atravs da exploraode falhas nos servios de rede;


32/49

Cavalo de Tria: programa com funo aparentemente til, que tambm realizaaes escondidas visando roubar informaes ou provocar danos no sistema;

Rootkit: conjunto de ferramentas usadas por um invasor para ocultar sua presenaem um sistema invadido. Os rootkits mais sofisticados envolvem modificaes noprprio sistema operacional, para ocultar os recursos (como processos, arquivos econexes de rede) usados pelo invasor.

A anlise de um malware consiste em estudar o contedo (anlise esttica) e ocomportamento (anlise dinmica) do programa, para descobrir seus objetivos, seu m-todo de propagao, sua forma de dissimulao no sistema, encontrar evidncias quepossam indicar sua presena ou atividade e implementar formas de detect-lo, remov-lodo sistema e impedir novas invases. A anlise esttica se baseia no estudo do cdigo

binrio do malware; ela cada vez mais difcil de realizar, devido ao emprego de tcnicasde dissimulao e cifragem [Beaucamps and Filiol 2007]. A anlise dinmica consiste naobservao da execuo do malware e de seus efeitos no sistema. Nesse contexto, o usode uma mquina virtual benfico, pelas seguintes razes:

No necessrio dedicar uma mquina real limpa para cada anlise;

Torna-se simples salvar e restaurar estados da mquina virtual, permitindo desfazeros efeitos de uma intruso; alm disso, a comparao entre os estados antes dedepois da intruso permite compreender melhor seus efeitos no sistema;

A verificao de informaes de baixo nvel (como o estado da memria, regis-tradores, dados dentro do ncleo) torna-se mais simples, atravs da capacidade deinspeo do hipervisor;

a traduo dinmica de instrues pode ser usada para instrumentar o fluxo de ins-trues executado pelo malware.

Com base nessas constataes, diversas ferramentas e servios de anlise din-mica automatizada de programas suspeitos tm sido propostos, como Anubis, CWSand-box e Joebox [Bayer et al. 2006, Willems et al. 2007]. Todavia, essa abordagem aindano perfeita. Vrios estudos recentes tm demonstrado que as implementaes atu-ais de hipervisores tm erros de projeto e/ou implementao que podem expor o sistemahospedeiro a ataques vindos do sistema convidado [Ormandy 2007], comprometendo asegurana do hipervisor e do prprio sistema hospedeiro. Alm disso, a virtualizao deplataformas correntes, como a de sistemas PC Intel x86, bastante complexa, estandosujeita a problemas na virtualizao de certos aspectos do hardware (conforme discutidona seo 4.1.3.3). Essas imperfeies abrem a porta para que malwares possam identi-ficar o sistema invadido e comportar-se de forma distinta caso estejam em uma mquinavirtual ou em um computador real [Raffetseder et al. 2007]. Com isso, a anlise dinmicado malware poder no corresponder sua execuo em um sistema real. Por outro lado,

outras pesquisas tm mostrado que h formas de tornar mais difcil a deteco de umsistema virtualizado por parte das aplicaes convidadas [Liston and Skoudis 2006].


33/49

Em [Kwan and Durfee 2007] proposta uma estrutura utilizando mquinas vir-tuais para verificao da integridade de um sistema. Neste sistema, chamado Vault, um

agente de verificao instalado nos hipervisores em uso. Estes agentes realizam a trocade mensagens visando garantir a segurana do sistema convidado monitorado. O princi-pio do projeto garantir que os sistemas monitorados no sejam subvertidos por malwaresconvencionais.

4.2.5. Honeypots e honeynets

Um honeypot um sistema explicitamente preparado para ser atacado e invadido. Os ho-neypots podem ser vistos como armadilhas, pois servem para atrair e estudar o trfegode rede malicioso, como worms e ataques humanos. Como o honeypot no correspondea servios legtimos da rede e pode ser facilmente atacado, serve como alerta para a pre-sena de atacantes na rede. Alm disso, ele desvia a ateno dos atacantes dos servidoresreais do sistema.

Os honeypots podem ser de baixa ou de alta interatividade. Nos honeypots debaixa interatividade, o atacante interage com emulaes de servios de rede, que no cor-respondem a servios reais e portanto no sero realmente comprometidos. Um exemplodessa abordagem o Honeyd, um daemon UNIX que emula vrias pilhas e servios derede [Provos 2004]. J os honeypots de alta interatividade expem sistemas e serviosreais que podem ser comprometidos aos atacantes. Honeypots de alta interatividadepodem ser perigosos se mal configurados, pois podem ser invadidos e usados como plata-formas para ataques ao restante da rede. Todavia, como os honeypots de alta interatividade

so sistemas reais, as observaes fornecidas por eles so mais detalhadas e correspondemmelhor realidade.

Uma honeynet [Honeynet Project 2001] uma coleo de honeypots de alta inte-ratividade com diferentes sistemas operacionais, configuraes e servios de rede. Por suadiversidade, essa rede tem um alto potencial de atrao de ataques. Alm dos honeypots,uma honeynet possui firewalls para evitar que trfego malicioso se propague a partir delapara outras redes, detectores de intruso para monitorar as atividades maliciosas e servi-dores de logging para o registro de eventos. A implantao de uma honeynet implica emalocar vrios computadores, com sistemas operacionais e servios distintos, o que podesignificar um alto custo de implantao e operao. Nesse contexto, mquinas virtuais

podem ser usadas para construir honeynets virtuais.Uma honeynet virtual [Honeynet Project 2003] simplesmente uma honeynet

construda com mquinas virtuais ao invs de computadores reais. A virtualizao trazvantagens, como o menor custo de implantao e gerncia, mas pode tambm trazer in-convenientes, como limitar as possibilidades de honeypots aos sistemas que podem ser vir-tualizados sobre a plataforma computacional escolhida. Alm disso, caso o sistema nativoseja comprometido, toda a honeynetestar comprometida. Para [Honeynet Project 2003],uma honeynetpode ser totalmente virtual, quando todos os computadores envolvidos somquinas virtuais, ou hbrida, quando composta por honeypots virtuais e mquinas reaispara as funes de firewall, deteco de intruso e logging.


34/49

4.2.6. Rootkits

Conforme apresentado na seo 4.2.4, um rootkit uma ferramenta que visa ocultar a

presena de um intruso no sistema. Os primeiros rootkits consistiam em substituir al-guns comandos do sistema (como ls, ps e netstat) por verses com a mesma fun-cionalidade, mas que escondiam os arquivos, processos e conexes de rede do intruso,tornando-o invisvel. Posteriormente, foram desenvolvidos rootkits mais elaborados,que substituem bibliotecas do sistema com a mesma finalidade. Os kernel rootkits con-sistem em mdulos de ncleo que alteram a implementao das chamadas de sistemadentro do ncleo, permitindo esconder o intruso de forma ainda mais profunda no sistema[Kruegel et al. 2004].

Recentemente, os avanos no suporte de hardware virtualizao possibilita-ram o desenvolvimento de rootkits baseado em mquinas virtuais, ou VM-based root-

kits (VMBR) [King and Chen 2006]. O funcionamento de um VMBR conceitualmentesimples: ao ser instalado, ele se torna um hipervisor, virtualizando todo o hardware damquina e transformando o sistema operacional invadido em um sistema convidado (con-forme apresentado na figura 4.23). Assim, toda a funcionalidade maliciosa do rootkitse encontra abaixo do sistema operacional (e fora do alcance dele), sendo teoricamenteindetectvel por detectores de rootkits convencionais.

Figura 4.23. Sistema antes e depois de ser afetado por um VMBR [King and Chen 2006].

Os rootkits baseados em virtualizao mais conhecidos so o Subvirt(que umaprova de conceito) [King and Chen 2006], o Vitriol (que usa a tecnologia VT-x dos proces-sadores Intel) [Zovi 2006] e o BluePill (que usa a tecnologia equivalente SVM, da AMD)

[Rutkowska 2006]. Embora os processadores sejam diferentes, o princpio de funciona-mento do suporte de hardware virtualizao anlogo em ambas as plataformas.


35/49

Da mesma forma que um hipervisor nativo, estes rootkits modificam a seqnciade inicializao da mquina afetada, carregando primeiro o seu cdigo e posteriormente o

sistema operacional original, em um ambiente convidado. Quando ativo, o VMBR torna-se incontornvel: ele pode interceptar todos os acessos ao hardware e inspecionar todo oestado interno do sistema operacional. Embora este tipo de rootkit seja teoricamente in-detectvel, vrios pesquisadores afirmam ser possvel detectar anomalias em um sistemavirtualizado, observado o comportamento dos processos, a alocao de recursos, diferen-as de temporizao nos acessos ao hardware, e falhas no suporte virtualizao, quepermitiriam detectar a presena desses rootkits [Rutkowska 2004, Garfinkel et al. 2007].

4.2.7. Consolidao de servidores, planos de contingncia e migrao

Uma das aplicaes mais freqentes da virtualizao a consolidao de servidores,que consiste em transferir servios em mquinas fsicas para mquinas virtuais, paradiminuir o nmero de equipamentos da organizao. Busca-se com isso aumentar aprodutividade da infra-estrutura, simplificar a gerncia do ambiente, aumentar a segu-rana, diminuir o consumo de energia e economizar recursos humanos, fsicos e finan-ceiros. Com a virtualizao, os recursos fsicos podem ser dinamicamente alocadosaos sistemas operacionais de acordo com suas necessidades, proporcionando balance-amento de carga dinmico e um melhor controle de uso dos recursos dos servidores[Newman et al. 2005, Ferre et al. 2006]. Alm disso, a reduo do nmero de equipa-mentos permite mais investimento em tecnologias de melhoria da disponibilidade, comofontes de alimentao redundantes e controladores de disco com suporte a hot-swapping.

Um plano de contingncia visa assegurar a disponibilidade de sistemas crticose facilitar a continuidade das operaes durante uma crise. Esse plano aplicado apsalgum incidente nos sistemas de computao. As mquinas virtuais podem desempenharum papel importante nos planos de contingncia de servidores e servios, a um custo dehardware e software relativamente baixo [Newman et al. 2005, Ferre et al. 2006]. Comomquinas virtuais podem ser salvas na forma de arquivos, checkpoints dos servidorescrticos podem ser salvos em equipamentos distintos. Assim, quando um servio falhar,uma cpia atualizada do mesmo pode ser rapidamente colocada em funcionamento.

Hipervisores modernos implementam facilidades de migrao de mquinas vir-tuais. Na migrao, uma mquina virtual e seu sistema convidado so transferidos de

um hipervisor para outro, executando em equipamentos distintos. A mquina virtual temseu estado preservado e prossegue sua execuo no hipervisor de destino assim que a mi-grao concluda. De acordo com [Clark et al. 2005], as tcnicas mais freqentes paraimplementar a migrao so:

stop-and-copy: consiste em suspender a mquina virtual, transferir o contedo desua memria para o hipervisor de destino e retomar a execuo em seguida. umaabordagem simples, mas implica em parar completamente os servios oferecidospelo sistema convidado enquanto durar a migrao (que pode demorar algumasdezenas de segundos);

demand-migration: a mquina virtual suspensa apenas durante a cpia das es-truturas de memria do ncleo para o hipervisor de destino, o que dura alguns


36/49


37/49

4.3. Exemplos de mquinas virtuais

Esta seo apresenta alguns sistemas de mquinas virtuais de uso corrente. Sero apre-

sentados os sistemas VMWare, FreeBSD Jails, Xen, User-Mode Linux, QEMU, Valgrinde JVM. Entre eles h mquinas virtuais de aplicao e de sistema, com virtualizao totalou paravirtualizao, alm de abordagens hibridas. Eles foram escolhidos por estarementre os mais representativos de suas respectivas classes.

4.3.1. VMware

Atualmente, o VMware a mquina virtual para a plataforma x86 de uso mais difundido,provendo uma implementao completa da interface x86 ao sistema convidado. Emboraessa interface seja extremamente genrica para o sistema convidado, acaba conduzindoa um hipervisor mais complexo. Como podem existir vrios sistemas operacionais em

execuo sobre mesmo hardware, o hipervisor tem que emular certas instrues pararepresentar corretamente um processador virtual em cada mquina virtual, fazendo usointensivo dos mecanismos de traduo dinmica [VMware 2000, Newman et al. 2005].Atualmente, a VMware produz vrios produtos com hipervisores nativos e convidados:

Hipervisor convidado:

VMware Workstation: primeira verso comercial da mquina virtual, lanadaem 1999, para ambientes desktop;

VMware Fusion: verso experimental para o sistema operacional Mac OS com

processadores Intel; VMware Player: verso gratuita do VMware Workstation, com as mesmas fun-

cionalidades mas limitado a executar mquinas virtuais criadas previamentecom verses comerciais;

VMWare Server: conta com vrios recursos do VMware Workstation, mas voltado para pequenas e mdias empresas;

Hipervisor nativo:

VMware ESX Server: para servidores de grande porte, possui um ncleo pro-prietrio chamado vmkernel e Utiliza o Red Hat Linux para prover outros ser-vios, tais como a gerncia de usurios.

O VMware Workstation utiliza as estratgias de virtualizao total e traduo di-nmica (seo 4.1.5). O VMware ESX Server implementa ainda a paravirtualizao.Por razes de desempenho, o hipervisor do VMware utiliza uma abordagem hbrida(seo 4.1.5.4) para implementar a interface do hipervisor com as mquinas virtuais[Sugerman et al. 2001]. O controle de exceo e o gerenciamento de memria so re-alizados por acesso direto ao hardware, mas o controle de entrada/sada usa o sistemahospedeiro. Para garantir que no ocorra nenhuma coliso de memria entre o sistemaconvidado e o real, o hipervisor VMware aloca uma parte da memria para uso exclusivode cada sistema convidado.


38/49

Para controlar o sistema convidado, o VMware Workstation intercepta todas asinterrupes do sistema convidado. Sempre que uma exceo causada no convidado,

examinada primeiro pelo hipervisor. As interrupes de entrada/sada so remetidas parao sistema hospedeiro, para que sejam processadas corretamente. As excees geradaspelas aplicaes no sistema convidado (como as chamadas de sistema, por exemplo) soremetidas para o sistema convidado.

4.3.2. FreeBSD Jails

O sistema operacional FreeBSD oferece um mecanismo de confinamento de processos de-nominado Jails, criado para aumentar a segurana de servios de rede. Esse mecanismoconsiste em criar domnios de execuo distintos (denominados jails ou celas), conformedescrito na seo 4.2.2. Cada cela contm um subconjunto de processos e recursos (ar-quivos, conexes de rede) que pode ser gerenciado de forma autnoma, como se fosse umsistema separado [Kamp and Watson 2000].

Cada domnio criado a partir de um diretrio previamente preparado no sistemade arquivos. Um processo que executa a chamada de sistema jail cria uma nova celae colocado dentro dela, de onde no pode mais sair, nem seus filhos. Alm disso, osprocessos em um domnio no podem:

Reconfigurar o ncleo (atravs da chamada sysctl, por exemplo);

Carregar/retirar mdulos do ncleo;

Mudar configuraes de rede (interfaces e rotas);

Montar/desmontar sistemas de arquivos;

Criar novos devices;

Realizar modificaes de configuraes do ncleo em tempo de execuo;

Acessar recursos que no pertenam ao seu prprio domnio.

Essas restries se aplicam mesmo a processos que estejam executando com pri-

vilgios de administrador (root).Pode-se considerar que o sistema FreeBSD Jails virtualiza somente partes do sis-

tema hospedeiro, como a rvore de diretrios (cada domnio tem sua prpria viso dosistema de arquivos), espaos de nomes (cada domnio mantm seus prprios identifica-dores de usurios, processos e recursos de IPC) e interfaces de rede (cada domnio temsua interface virtual, com endereo IP prprio). Os demais recursos (como as instruesde mquina e chamadas de sistema) so preservadas, ou melhor, podem ser usadas dire-tamente. Essa virtualizao parcial demanda um custo computacional muito baixo, masexige que todos os sistemas convidados executem sobre o mesmo ncleo.


39/49

4.3.3. Xen

O ambiente Xen um hipervisor nativo para a plataforma x86 que implementa a para-

virtualizao. Ele permite executar sistemas operacionais como Linux e Windows es-pecialmente modificados para executar sobre o hipervisor [Barham et al. 2003]. Versesmais recentes do sistema Xen utilizam o suporte de virtualizao disponvel nos proces-sadores atuais, o que torna possvel a execuo de sistemas operacionais convidados semmodificaes, embora com um desempenho ligeiramente menor que no caso de sistemasparavirtualizados. Conforme seus criadores, o custo e impacto das alteraes nos sistemasconvidados so baixos e a diminuio do custo da virtualizao compensa essas altera-es (a degradao mdia de desempenho observada em sistemas virtualizados sobre aplataforma Xen no excede 5%). As principais modificaes impostas pelo ambiente Xena um sistema operacional convidado so:

O mecanismo de entrega de interrupes passa a usar um servio de eventos ofere-cido pelo hipervisor; o ncleo convidado deve registrar um vetor de tratadores deexcees junto ao hipervisor;

as operaes de entrada/sada de dispositivos so feitas atravs de uma interfacesimplificada, independente de dispositivo, que usa buffers circulares de tipo produ-tor/consumidor;

o ncleo convidado pode consultar diretamente as tabelas de segmentos e pginasda memria usada por ele e por suas aplicaes, mas as modificaes nas tabelas

devem ser solicitadas ao hipervisor;

o ncleo convidado deve executar em um nvel de privilgio inferior ao do hipervi-sor;

o ncleo convidado deve implementar uma funo de tratamento das chamadas desistema de suas aplicaes, para evitar que elas tenham de passar pelo hipervisorantes de chegar ao ncleo convidado.

Como o hi

Documents

Virutalizacao2