Problemas de segurança com memória compartilhada da VM (Máquina Virtual) do NDIS

Este tópico discute os possíveis problemas de segurança envolvidos na alocação de memória compartilhada de uma VM (máquina virtual) para buffers de recebimento de VMQ (fila de máquinas virtuais). O tópico inclui as seguintes seções:

• Visão geral dos problemas de segurança com memória compartilhada da VM

• Como o Windows Server 2008 R2 resolve o problema de segurança

• Como o Windows Server 2012 e versões posteriores resolvem o problema de segurança

Nota No Hyper-V, uma partição filho também é conhecida como uma VM.

Visão geral dos problemas de segurança com memória compartilhada da VM

As VMs não são entidades de software confiáveis. Ou seja, uma VM mal-intencionada não deve ser capaz de interferir com outras VMs ou com o sistema operacional de gerenciamento executado na partição pai Hyper-V. Esta seção fornece informações de base e requisitos para garantir que os desenvolvedores de drivers entendam os problemas de segurança e os requisitos do VMQ para memória compartilhada. Para obter mais informações sobre memória compartilhada, consulte o tópico Alocação de Recursos de Memória Compartilhada na seção Gravar Drivers VMQ .

No ambiente virtualizado, a memória compartilhada da VM pode ser exibida ou modificada pela VM. No entanto, não é permitido exibir ou modificar dados associados a outras VMs. As VMs também não têm permissão para acessar o espaço de endereço operacional de gerenciamento.

A parte do cabeçalho dos pacotes recebidos deve ser protegida. Uma VM não tem permissão para afetar o comportamento do comutador extensível Hyper-V em um VSP (provedor de serviços virtuais de rede). Portanto, a filtragem de VLAN (LAN virtual) deve acontecer antes que o adaptador de rede use o DMA para transferir os dados para a memória compartilhada da VM. Além disso, o aprendizado do endereço MAC (controle de acesso à mídia) do switch não pode ser comprometido.

Se a porta de comutador extensível Hyper-V que está conectada a uma VM tiver um identificador VLAN associado, o computador host deverá garantir que o endereço MAC de destino e o identificador de VLAN do quadro de chegada correspondam às respectivas propriedades da porta antes que o host encaminhe o pacote para o adaptador de rede virtual da VM. Se o identificador de VLAN do quadro não corresponder ao identificador VLAN da porta, o pacote será descartado. Quando os buffers de recebimento de um adaptador de rede virtual são alocados da memória do host, o host pode verificar o identificador de VLAN e remover o quadro, se necessário, antes de tornar o conteúdo do quadro visível para a VM de destino. Se o quadro não for copiado para o espaço de endereço de uma VM, ele não poderá ser acessado por essa VM.

No entanto, quando o VMQ está configurado para usar a memória compartilhada, o adaptador de rede usa o DMA para transferir quadros de entrada diretamente para o espaço de endereço da VM. Essa transferência apresenta um problema de segurança no qual uma VM pode examinar o conteúdo dos quadros recebidos sem esperar que a opção extensível aplique a filtragem de VLAN necessária.

Como o Windows Server 2008 R2 resolve o problema de segurança

No Windows Server 2008 R2, antes que o VSP configure uma fila de VM para usar a memória compartilhada alocada do espaço de endereço da VM, ele usa o teste de filtragem a seguir para a fila.

(MAC address == x) && (VLAN identifier == n)

Se o hardware do adaptador de rede puder dar suporte a esse teste antes da transferência de DMA para os buffers de recebimento, o adaptador de rede poderá remover quadros com identificadores VLAN inválidos ou enviá-los para a fila padrão para que possam ser filtrados pelo comutador extensível. Se o driver de miniporto tiver êxito em uma solicitação para definir um filtro com esse teste em uma fila, o comutador extensível poderá usar a memória compartilhada da VM para essa fila. No entanto, se o hardware do adaptador de rede não for capaz de filtrar os quadros com base no endereço MAC de destino e no identificador VLAN, o comutador extensível usará a memória compartilhada do host para essa fila.

O comutador extensível inspeciona o endereço MAC de origem dos quadros recebidos para configurar as informações de roteamento para quadros de transmissão, ou seja, é semelhante a um comutador de aprendizado físico. É possível instalar drivers de filtro de firewall na pilha de host; por exemplo, acima do driver de miniporto para o hardware do adaptador de rede e abaixo do driver de comutador extensível. Os drivers de filtro de firewall podem acessar dados em um quadro recebido antes da opção extensível. Se todo o buffer de recebimento de cada quadro for alocado do espaço de endereço da VM, uma VM mal-intencionada poderá acessar partes do quadro que seriam examinadas por um driver de filtro ou pelo comutador extensível executado no host.

Para resolver esse problema de segurança, ao usar a memória compartilhada da VM para uma fila de VM, o adaptador de rede deve dividir o pacote em um deslocamento de bytes que seja pelo menos o tamanho do lookahead, que é um valor fixo predeterminado. Todos os dados de lookahead, ou seja, dados que estão à frente do deslocamento de bytes para o tamanho do lookahead, devem ser transferidos com DMA para a memória compartilhada que foi alocada especificamente para dados de lookahead. Os dados pós-lookahead — a carga útil restante do quadro — devem ser transferidos com DMA para memória compartilhada alocada para esses dados pós-lookahead.

A ilustração a seguir mostra as relações das estruturas de dados de rede quando os dados de entrada são divididos em buffers de memória compartilhada lookahead e pós-lookahead.

Os requisitos de resumo da memória compartilhada do VMQ são os seguintes:

• Um adaptador de rede pode dividir um quadro recebido em um limite de cabeçalho de rede maior que o tamanho do lookahead. No entanto, quando solicitado pelo NDIS e sem exceção, todos os quadros recebidos e atribuídos a um VMQ devem ser divididos em ou além do limite de tamanho lookahead que o NDIS solicita.

• Os dados lookahead devem ser transferidos com DMA para memória compartilhada alocada pelo driver de miniport. O driver de miniporto deve especificar na chamada de alocação que a memória será usada para dados de antecipação.

• Os dados pós-lookahead devem ser transferidos com DMA para memória compartilhada alocada pelo driver de miniporto. O miniport driver deve especificar na chamada de alocação que a memória será usada para dados pós-antecipação.

• Os drivers de miniporto não devem depender do espaço de endereço que o NDIS usará para concluir a solicitação de alocação de memória compartilhada. Ou seja, o espaço de endereço de memória compartilhado para dados lookahead ou pós-lookahead é específico para implementação. Em muitos casos, o NDIS ou o comutador extensível podem atender a todas as solicitações, inclusive aquelas para uso pós-lookahead, do espaço de endereço de memória do host.

• A ordem na qual os quadros são recebidos em uma fila de recebimento de VMQ deve ser preservada quando os quadros nessa fila são indicados na pilha do driver.

• O adaptador de rede deve alocar espaço de memória de backfill suficiente em cada buffer de pós-visão antecipada. Essa alocação permite que os dados de lookahead sejam copiados para a parte de preenchimento do buffer pós-lookahead, permitindo que o quadro seja entregue à VM em um buffer contíguo.

Se não houver nenhum mecanismo no hardware para atender a esses requisitos de memória compartilhada do VMQ, o hardware que dá suporte ao DMA de coleta de dispersão no lado de recebimento poderá obter os mesmos resultados alocando dois buffers de recebimento para cada quadro recebido. Nesse caso, o tamanho do primeiro buffer é limitado ao tamanho do lookahead solicitado.

Se o adaptador de rede não puder atender a esses requisitos de memória compartilhada do VMQ por qualquer método, o VSP alocará memória do espaço de endereço do host para os buffers de recepção do VMQ e copiará os pacotes recebidos dos buffers de recepção do adaptador de rede para o espaço de endereço da VM.

Como o Windows Server 2012 e versões posteriores resolvem o problema de segurança

A partir do Windows Server 2012, o VSP não aloca memória compartilhada da VM para os buffers de recebimento do VMQ. Em vez disso, o VSP aloca memória para os buffers de recebimento do VMQ a partir do espaço de endereço do host e, em seguida, copia os pacotes recebidos dos buffers de recebimento do adaptador de rede para o espaço de endereço da VM.

Os seguintes pontos se aplicam aos drivers de miniporto VMQ executados no Windows Server 2012 e versões posteriores do Windows:

• Para drivers de miniporto NDIS 6.20 VMQ, nenhuma alteração é necessária. No entanto, quando o VSP aloca uma fila de VM emitindo uma solicitação de método OID (identificador de objeto) de OID_RECEIVE_FILTER_ALLOCATE_QUEUE, ele definirá o membro LookaheadSize da estrutura NDIS_RECEIVE_QUEUE_PARAMETERS como zero. Isso forçará um driver de miniporto a não dividir o pacote em buffers pré-lookahead e pós-lookahead.

• A partir do NDIS 6.30, os drivers miniport VMQ não devem anunciar suporte para dividir dados de pacotes em buffers de pré-análise e pós-análise. Quando um driver de miniporto registra seus recursos de VMQ, ele deve seguir estas regras quando inicializa a estrutura NDIS_RECEIVE_FILTER_CAPABILITIES :

  • O driver do miniporto não deve definir a flag NDIS_RECEIVE_FILTER_LOOKAHEAD_SPLIT_SUPPORTED no membro Flags.

  • O driver de miniporto deve definir os membros MinLookaheadSplitSize e MaxLookaheadSplitSize como zero.

  Para obter mais informações sobre como registrar recursos de VMQ, consulte Determining the VMQ Capabilities of a Network Adapter.