RSS
Blog
Série de imagens de artigos Xen, parte 3

Virtualização e computação em nuvem Xen # 03: Principais recursos do Xen

15 de outubro de 2020 - por Mohsen Mostafa Jokar

Os artigos anteriores desta série introduziram a virtualização e mostraram como o Xen foi projetado para fornecê-la com eficiência. Aqui, vamos nos aprofundar em alguns recursos interessantes e sua importância. Uma lista maior pode ser encontrada no local apropriado página do projeto em recursos. No momento em que escrevia este artigo, a versão mais recente do Projeto Xen era a 4.13.

Recursos relacionados à segurança

The Meltdown and Spectre as vulnerabilidades do processador, que exploram recursos complexos de aprimoramento de desempenho de microprocessadores modernos, apresentam desafios formidáveis ​​para os desenvolvedores de sistemas operacionais e aplicativos. Meltdown e Spectre foram descobertos oficialmente em janeiro de 2018. Esta seção descreve duas melhorias no Xen para mitigar essas vulnerabilidades difíceis.

Mascote Xen Panda

O Meltdown, que afeta Intel x86, IBM Power e alguns microprocessadores ARM, permite que um processo malicioso leia dados de qualquer endereço mapeado para o espaço de memória do processo atual. Efetivamente, o processo pode ler toda a memória sem permissão. O processo malicioso consegue isso encontrando uma falha de tempo na execução de vários recursos do processador (como o cache e o pipeline) que são individualmente seguros. No momento da divulgação, essa vulnerabilidade afetava muitos produtos, com impactos em um enorme número de servidores e provedores de nuvem. As empresas começaram a escrever patches para bloquear a vulnerabilidade Meltdown, causando perdas de desempenho entre 5 e 30 por cento.

Spectre também explora recursos de desempenho modernos. Nos microprocessadores modernos, um circuito digital tenta adivinhar o resultado de uma operação condicional, como uma instrução “if… else”, usando informações coletadas antes da execução do programa e se prepara para o resultado mais provável. Isto. Em outras palavras, ele tenta adivinhar o caminho de uma instrução if-then-else antes de saber exatamente. O nome dessa técnica é previsão de ramificação. É um componente importante das arquiteturas de CPU modernas, como o x86, e desempenha um papel crítico na obtenção de um desempenho superior. Spectre explora o sistema de predicação de ramais para ler localizações arbitrárias na memória alocada de um programa. Esse ataque pode ser implementado em um navegador usando JavaScript, por isso é importante manter seu navegador atualizado.

Em 15 de março de 2018, a Intel relatou que redesenhará seus processadores CPU para ajudar a proteger contra Meltdown e Spectre. Em 8 de outubro de 2018, a Intel adicionou firmware a seus processadores mais recentes para mitigar esses ataques.

Alterações do hipervisor para mitigar o Meltdown e Spectre

O hipervisor Xen, como outros produtos, foi afetado por estas vulnerabilidades, especificamente:

  • “Rogue Data Load” (também conhecido como SP3, “Variant 3”, Meltdown, CVE-2017-5754)
  • “Branch Target Injection” (também conhecido como SP2, “Variant 2”, Spectre CVE-2017-5715)
  • “Bypass de verificação de limites” (também conhecido como SP1, “Variante 1”, Spectre CVE-2017-5753)

Não há como evitar completamente os riscos dessas vulnerabilidades, mas adicionar limites de execução e outras verificações ao código pode tampar parcialmente os buracos. Assim, falamos em “mitigar” as vulnerabilidades.

O foco inicial do Projeto Xen estava nas correções para Meltdown, depois para Specter Variant 2 e, finalmente, para Specter Variant 1. SP1 e SP2 afetam os processadores Intel e AMD, mas os processadores ARM variam de acordo com o modelo e o fabricante. O SP3 afeta apenas os processadores Intel. Para mitigar o Meltdown, o Projeto Xen publicou três soluções com os nomes Vixen, Comet e PTI. Infelizmente, a correção para mitigar o SP1 requer atualizações de microcódigo da Intel e AMD. Atualmente, portanto, não há mitigação para o SP1. Mas sua superfície de ataque pode ser reduzida por meio da tecnologia fornecida ao Projeto Xen da Citrix. Funciona por endurecimento de ramos.

  • O SP2 pode ser mitigado por uma combinação de alterações de microcódigo, compilador e hipervisor.
  • O SP3 pode ser atenuado pelo isolamento da tabela de páginas (PTI).

Para obter informações mais atualizadas sobre essas vulnerabilidades e as respostas do Projeto Xen, consulte nossa Consultoria 254.

Programação Principal

Essa tecnologia, fornecida pela SuSE Linux, ajuda a conter os efeitos negativos de uma violação de Meltdown ou Spectre. Normalmente, cada CPU virtual pode ser agendada em qualquer CPU física e pode se mover entre CPUs físicas para agendamento eficiente. Isso aumentava o risco de vazamento de informações de uma VM para outra, da mesma forma que viajar entre as cidades permite que uma infecção se espalhe mais rapidamente. A única maneira de atenuar completamente essa vulnerabilidade é desabilitar o hyper-threading, o que causaria enormes acessos de desempenho.

O recurso de agendamento de núcleo permite que o Xen agrupe CPUs virtuais e agende-as em um conjunto limitado de núcleos físicos. Com essa tecnologia, os usuários podem manter o hyperthreading ativado. Os benchmarks iniciais mostraram desempenho perdido para muitas cargas de trabalho. SUSE e Citrix estão trabalhando no recurso e, nas próximas versões, esperamos ver melhores compensações entre segurança e desempenho.

Introspecção de memória baseada em hipervisor (HVMI)

Esta é uma tecnologia doada por Bitdefender para o projeto Xen em 30 de julho de 2020 para proteger contra malware nos sistemas operacionais executados no Xen. HVMI tem uma vantagem importante sobre os sistemas de detecção de malware em sistemas operacionais convidados: enquanto o malware inteligente pode assumir o controle de um convidado inteiro e desabilitar os mecanismos de detecção ou prevenção no convidado, o malware não tem como acessar o hipervisor subjacente.

O malware se tornou extremamente perigoso e difícil de combater por vários motivos:

  • Ele pode entrar no sistema sempre que um único usuário desavisado do sistema visita um site infectado ou abre um arquivo recebido de uma pessoa confiável.
  • Ele pode explorar vulnerabilidades do sistema operacional para obter privilégios de superusuário e assumir o controle de todo o sistema. Muito poucos sistemas operacionais dividem privilégios para limitar o malware a uma área.
  • Ele se tornou sofisticado o suficiente para ocultar seus arquivos ou outros rastros dos administradores e para desabilitar medidas destinadas a impedi-lo.

Uma história notável que mostra o poder do malware diz respeito a um ataque conhecido como Carbanak, que infectou mais de 100 bancos em trinta nações e causou danos de US $ 1 bilhão em todo o mundo. No final de 2013, uma investigação de um banco em Kiev revelou que o malware stealth injetado por Carbanak monitorou os sistemas internos do banco por vários meses, cobrindo com sucesso seus rastros. O malware registrava a atividade de cada funcionário e enviava vídeos e imagens ao invasor sem chamar atenção.

A Bitdefender o nome é familiar a todos os funcionários de TI. É uma empresa líder global em segurança cibernética, protegendo mais de 500 milhões de sistemas em todo o mundo. Bitdefender e Citrix colaboraram em Citrix Hypervisor. Como sabemos, o hipervisor isola as VMs umas das outras e fornece informações limpas e de baixo nível sobre a memória usada por cada máquina virtual. O resultado dessa colaboração é uma nova camada de segurança que pode ver tudo o que está acontecendo em sua infraestrutura, mas que o Malware não consegue alcançar. A tecnologia Hypervisor Introspection (HVI) do Bitdefender detecta atividades suspeitas trabalhando diretamente com a memória bruta. Nesse nível, o malware não pode se esconder.

O Bitdefender HVI assume que seus sistemas não estão limpos e você pode comandá-lo para injetar ferramentas de limpeza nas máquinas virtuais ativas. O HVI já detecta e bloqueia os ataques mais famosos, incluindo Carbanak, Turla, APT28, NetTraveler e Wild Neutron, sem conhecer as vulnerabilidades utilizadas pelos atacantes.

Quando o Bitdefender decidiu liberar HVI para Xen como código aberto, eles o chamaram de Introspecção de Memória baseada em hipervisor (HVMI). A tecnologia HVMI entende e aplica lógica de segurança a eventos de memória em VMs Linux e Windows em execução. Ele examina a memória em tempo real em busca de sinais de técnicas de ataque com base na memória que costumavam explorar vulnerabilidades conhecidas e desconhecidas.

Junto com isso, o Bitdefender abriu o código-fonte de sua tecnologia de hipervisor "fina", conhecida como Napoca, e doou para o Projeto Xen. O hipervisor Napoca foi usado no desenvolvimento da tecnologia HVI. Uma característica distintiva do Napoca é que ele virtualiza CPU e memória, não todo o hardware e, portanto, permite a introspecção do hipervisor em máquinas que não executam um hipervisor completo.

Recursos relacionados à gestão

Esses recursos reduzem a carga de gerenciamento de hipervisores.

Carregamento atrasado do uCode

Microcódigo, frequentemente abreviado como “uCode” (onde o “u” significa a letra grega mu), é o firmware do fabricante do chip. O uCode normalmente contém atenuações para vulnerabilidades de HW e é normalmente atualizado durante a inicialização do sistema ou inicialização do kernel. A atualização anteriormente exigia uma reinicialização e um longo tempo de inatividade. O Xen Project 4.13 permite que o Xen Hypervisor implante uma atualização do uCode sem qualquer reinicialização. Este recurso foi contribuído pela Intel.

Patches ao vivo atualizados

Este é um mecanismo para substituir pequenas seções de código em um hipervisor em execução, de modo que você não precise desligar o hipervisor e encerrar todas as VMs em execução nele. O recurso é geralmente usado para implementar correções de segurança críticas.

Patching ao vivo já existe há algum tempo em vários produtos baseados no Xen e foi incluído como um recurso de visualização técnica desde o Xen 4.7. Agora é um recurso com suporte na arquitetura x86. O patching precisa que toda a atividade seja pausada, mas esse tempo de pausa deve ser pequeno. A Amazon está trabalhando para melhorar ainda mais esse recurso. Planejamos estendê-lo para outras arquiteturas além do x86.

Melhorias recentes para patching ao vivo incluem a capacidade de corrigir o código assembly em linha, melhorias para módulos empilhados, suporte para parâmetros de módulo, ganchos adicionais e ações replicáveis ​​de aplicar / reverter, ligações estendidas de Python para automação e validação adicional de patches ao vivo.

O patch ao vivo não é o objetivo final das atualizações ao vivo, porque é limitado a pequenas alterações de código localizadas. A equipe do Projeto Xen também está trabalhando em um recurso de atualização ao vivo mais amplo. Quando terminar, um administrador poderá atualizar um hipervisor Xen e suas ferramentas para uma nova versão sem parar e reiniciar os convidados.

Recursos de aplicativos integrados e essenciais para a segurança

Esses recursos oferecem suporte a configurações específicas que precisam executar o hipervisor e as VMs de maneiras incomuns.

Suporte OP-TEE

TrustZone é um recurso de segurança dos processadores ARM, permitindo que usuários com privilégios executem um processo em uma memória desligada do acesso por outros processos. Como há apenas uma zona confiável em cada chip, compartilhar entre várias VMs é difícil. Portanto, o Xen não ofereceu originalmente acesso TrustZone às VMs convidadas. Graças a um recurso contribuído por EPAM, a partir do Xen 4.13, todos os convidados podem executar aplicativos simultaneamente no Arm TrustZone sem conflitos. Mais trabalho precisa ser feito neste recurso, no entanto.

Driver Renesas R-CAR IPMMU-VMSA

Os automóveis dependem cada vez mais de software. Seus vários processos de software simultâneos exigem virtualização para proteger a segurança de alto risco exigida nos automóveis. Portanto, muitos sistemas automotivos usam hipervisores Xen. O acesso às GPUs é valioso para os processos virtuais, a fim de atingir o desempenho em tempo real necessário quando o carro está em movimento, mas isso requer acesso à Arquitetura do Sistema de Memória Virtual (VMSA) da ARM. A Renesas adicionou este suporte VMSA a seus chips baseados em ARM no Xen 4.13, e um driver contribuído para o Projeto Xen pela EPAM torna esse acesso disponível para sistemas de computação de automóveis.

Passthrough sem Dom0 e ImageBuilder

Um artigo anterior desta série descreveu a função central do domínio privilegiado, Dom0, no Xen. Como a presença do Dom0 adiciona um tempo significativo (mensurável em segundos) ao carregamento de cada VM, alguns desenvolvedores de sistemas incorporados pediram uma arquitetura sem Dom0. Muitos sistemas embarcados precisam ter várias VMs instaladas e funcionando em menos de um segundo após o usuário inicializar o sistema. O código para implementar uma arquitetura Dom0-less foi contribuído por Xilinx em 2018. O recurso ainda não funciona com a Paravirtualização, mas funciona com outras formas de virtualização Xen.

Como não há nenhum processo privilegiado e nenhuma ferramenta de espaço de usuário em um Xen sem Dom0, os sistemas que o usam devem carregar convidados usando U-Boot, um carregador de boot de código aberto. As imagens de convidado devem conter todos os binários necessários, como kernels do sistema operacional e ramdisks. Assim, uma nova ferramenta chamada ImageBuilderDe quem o código está no GitLab, é fornecido para automatizar a construção de configurações sem Dom0 para U-Boot.

A Figura 4 mostra uma arquitetura sem Dom0.

Figura 4. Xen rodando sem Dom0
Figura 4. Xen rodando sem Dom0

O próximo componente desta série examina o relacionamento interessante entre o Xen e algumas outras formas de virtualização, principalmente contêineres.

Leia a postagem anterior

Sobre Mohsen Mostafa Jokar:

Mohsen Mostafa Jokar


Mohsen Mostafa Jokar é administrador Linux e engenheiro de virtualização. Seu interesse em virtualização remonta aos tempos de escola, quando viu o Microsoft Virtual PC pela primeira vez. Ele o instalou em um PC com 256 MB de RAM e o usou para virtualizar o Windows 98 e DOS. Depois disso, Mohsen se interessou pela virtualização e se familiarizou com mais produtos.

Junto com a virtualização, Mohsen se familiarizou com o GNU / Linux. Ele instalou o LindowsOS como sua primeira distro Linux, mais tarde se familiarizando com o Fedora Core, Knoppix, RedHat e outras distribuições. Usando o sistema operacional Linux, ele se familiarizou com o bochs, mas achou-o muito lento e, após algumas pesquisas, descobriu o Qemu. Qemu era mais rápido do que bochs, e instalar o módulo KQEMU permitiu que ele fizesse a virtualização ainda mais rápido. Depois do Qemu, Mohsen conheceu o Innotek VirtualBox e o escolheu como seu principal aplicativo de virtualização. O Innotek VirtualBox tinha uma boa interface de usuário e era fácil de usar.

No final das contas, Mohsen conheceu o Xen, que ele ama porque é forte, estável e confiável. Ele escreveu um livro sobre o Xen com o nome "Hello Xen Project" e o disponibilizou na wiki do Xen. Ele o tornou gratuito para ajudar a tornar o Xen mais amigável e incentivar os iniciantes a usá-lo como sua primeira plataforma de virtualização. Ele se considera um "Soldado Xen". "