Sobre a escolha do tipo de agendador do Hipervisor Hyper-V
Este documento descreve alterações importantes no uso padrão do Hyper-V e o uso recomendado de tipos de agendador de hipervisor. Essas alterações afetam a segurança do sistema e o desempenho da virtualização. Os administradores de host de virtualização devem examinar e entender as alterações e implicações descritas neste documento e avaliar cuidadosamente os impactos, as diretrizes de implantação sugeridas e os fatores de risco envolvidos para entender melhor como implantar e gerenciar hosts Hyper-V diante do cenário de segurança em rápida mudança.
Importante
Atualmente, vulnerabilidades de segurança do lado do canal conhecidas vistas em várias arquiteturas de processador podem ser exploradas por uma VM convidada mal-intencionada com o comportamento de agendamento do tipo de agendador clássico do hipervisor herdado quando executado em hosts com SMT (Multithreading Simultâneo) habilitado. Se explorada com êxito, uma carga de trabalho mal-intencionada poderá observar dados fora de seu limite de partição. Essa classe de ataques pode ser atenuada com a configuração do hipervisor Hyper-V para utilizar o tipo de agendador principal do hipervisor e a reconfiguração de VMs convidadas. Com o agendador principal, o hipervisor restringe os VPs de uma VM convidada a serem executados no mesmo núcleo de processador físico, isolando fortemente a capacidade da VM de acessar dados até os limites do núcleo físico no qual ela é executada. Essa é uma mitigação altamente eficaz contra esses ataques do lado do canal, o que impede que a VM observe artefatos de outras partições, seja a raiz, seja outra partição de convidado. Portanto, a Microsoft está alterando as configurações padrão e as recomendadas para hosts de virtualização e VMs convidadas.
Tela de fundo
Desde o Windows Server 2016, o Hyper-V dá suporte a vários métodos de agendamento e gerenciamento de processadores virtuais, chamados de tipos de agendador de hipervisor. Uma descrição detalhada de todos os tipos de agendador de hipervisor pode ser encontrada em Noções básicas e uso de tipos de agendador de hipervisor do Hyper-V.
Observação
Novos tipos de agendador de hipervisor foram apresentados pela primeira vez no Windows Server 2016 e não estão disponíveis em versões anteriores. Todas as versões do Hyper-V antes do Windows Server 2016 dão suporte apenas ao agendador clássico. O suporte ao agendador principal só foi publicado recentemente.
Sobre os tipos de agendador do hipervisor
Este artigo se concentra especificamente no uso do novo tipo de agendador principal do hipervisor em comparação com o agendador "clássico" herdado e como esses tipos de agendador se cruzam com o uso de Multi-Threading Simétrico, ou SMT. É importante entender as diferenças entre os agendadores principais e clássicos e como cada local funciona de VMs convidadas nos processadores do sistema subjacentes.
O agendador clássico
O agendador clássico refere-se ao método round robin de compartilhamento justo de agendamento de trabalho em VPs (processadores virtuais) em todo o sistema, incluindo VPs raiz, bem como VPs pertencentes a VMs convidadas. O agendador clássico tem sido o tipo de agendador padrão usado em todas as versões do Hyper-V (até o Windows Server 2019, conforme descrito aqui). As características de desempenho do agendador clássico são bem compreendidas e o agendador clássico é demonstrado como capaz de dar suporte ao excesso de assinaturas de cargas de trabalho, ou seja, excesso de assinaturas da proporção VP:LP do host por uma margem razoável (dependendo dos tipos de cargas de trabalho que estão sendo virtualizadas, utilização geral de recursos, etc.).
Quando executado em um host de virtualização com SMT habilitado, o agendador clássico agendará VPs convidados de qualquer VM em cada thread SMT pertencente a um núcleo independentemente. Portanto, diferentes VMs podem ser executadas no mesmo núcleo ao mesmo tempo (uma VM em execução em um thread de um núcleo enquanto outra VM está em execução no outro thread).
O agendador principal
O agendador principal aproveita as propriedades do SMT para fornecer isolamento de cargas de trabalho de convidado, o que afeta a segurança e o desempenho do sistema. O agendador principal garante que os VPs de uma VM sejam agendados em threads SMT irmãos. Isso é feito simetricamente para que, se os LPs estiverem em grupos de dois, os VPs sejam agendados em grupos de dois e um núcleo de CPU do sistema nunca seja compartilhado entre VMs.
Ao agendar VPs convidados em pares SMT subjacentes, o agendador principal oferecerá um forte limite de segurança para isolamento de carga de trabalho e também poderá ser usado para reduzir a variabilidade do desempenho em cargas de trabalho dependentes de latência.
Observe que quando o VP é agendado para uma máquina virtual sem SMT habilitado, esse VP consumirá todo o núcleo quando for executado e o thread SMT irmão do núcleo ficará ocioso. Isso é necessário para fornecer o isolamento correto da carga de trabalho, mas afeta o desempenho geral do sistema, especialmente à medida que os LPs do sistema se tornam excessivamente assinados, ou seja, quando a proporção total de VP:LP excede 1:1. Portanto, a execução de VMs convidadas configuradas sem vários threads por núcleo é uma configuração abaixo do ideal.
Benefícios do uso do agendador principal
O agendador principal oferece os seguintes benefícios:
Um forte limite de segurança para isolamento de carga de trabalho de convidado: os VPs convidados são restritos a serem executados em pares de núcleos físicos subjacentes, reduzindo a vulnerabilidade a ataques de espionagem do lado do canal.
Variabilidade reduzida da carga de trabalho: a variabilidade da taxa de transferência da carga de trabalho convidada é bastante reduzida, o que oferece maior consistência de carga de trabalho.
Uso do SMT em VMs convidadas – o sistema operacional e os aplicativos em execução na máquina virtual convidada podem utilizar o comportamento SMT e as APIs (interfaces de programação) para controlar e distribuir o trabalho entre threads SMT, assim como fariam quando executados sem virtualização.
O agendador principal é usado atualmente em hosts de virtualização do Azure, especificamente para aproveitar o limite de segurança forte e a baixa variabilidade da carga de trabalho. A Microsoft acredita que o tipo de agendador principal deve ser e continuará sendo o tipo de agendamento de hipervisor padrão para a maioria dos cenários de virtualização. Portanto, para garantir que nossos clientes fiquem protegidos por padrão, a Microsoft está fazendo essa alteração para o Windows Server 2019 agora.
Principais impactos no desempenho do agendador nas cargas de trabalho de convidado
Embora seja necessário atenuar efetivamente determinadas classes de vulnerabilidades, o agendador principal também pode reduzir potencialmente o desempenho. Os clientes podem ver uma diferença nas características de desempenho com suas VMs e impacto na capacidade geral da carga de trabalho de seus hosts de virtualização. Nos casos em que o agendador principal precisar executar um VP não SMT, apenas um dos fluxos de instrução no núcleo lógico subjacente será executado enquanto o outro deverá ficar ocioso. Isso limitará a capacidade total do host em cargas de trabalho de convidado.
Esses impactos no desempenho podem ser minimizados com o cumprimento das diretrizes de implantação neste documento. Os administradores de host precisam considerar cuidadosamente seus cenários específicos de implantação de virtualização e equilibrar sua tolerância ao risco de segurança com a necessidade de densidade máxima de carga de trabalho, o excesso de consolidação de hosts de virtualização, etc.
Alterações nas configurações padrão e recomendadas para Windows Server 2016 e Windows Server 2019
A implantação de hosts Hyper-V com a postura de segurança máxima requer o uso do tipo de agendador principal do hipervisor. Para garantir que nossos clientes fiquem protegidos por padrão, a Microsoft está alterando as configurações padrão e recomendadas a seguir.
Observação
Embora o suporte interno do hipervisor para os tipos de agendador tenha sido incluído na versão inicial do Windows Server 2016, do Windows Server 1709 e do Windows Server 1803, atualizações são exigidas para acessar o controle de configuração que permite selecionar o tipo de agendador do hipervisor. Consulte Noções básicas e uso de tipos de agendador de hipervisor do Hyper-V para obter detalhes sobre essas atualizações.
Alterações no host de virtualização
O hipervisor usará o agendador principal por padrão a partir do Windows Server 2019.
A Microsoft confirma a configuração do agendador principal no Windows Server 2016. Há suporte ao tipo de agendador principal do hipervisor no Windows Server 2016; no entanto, o padrão é o agendador clássico. O agendador principal é opcional e precisa ser habilitado explicitamente pelo administrador de host do Hyper-V.
Alterações na configuração da máquina virtual
No Windows Server 2019, novas máquinas virtuais criadas com a VM padrão versão 9.0 herdarão automaticamente as propriedades SMT (habilitadas ou desabilitadas) do host de virtualização. Ou seja, se o SMT estiver habilitado no host físico, as VMs recém-criadas também terão o SMT habilitado e herdarão a topologia SMT do host por padrão, com a VM tendo o mesmo número de threads de hardware por núcleo que o sistema subjacente. Isso será refletido na configuração da VM com HwThreadCountPerCore = 0, em que 0 indica que a VM deve herdar as configurações de SMT do host.
As máquinas virtuais existentes com uma versão de VM 8.2 ou anterior manterão a configuração original do processador de VM para HwThreadCountPerCore, e o padrão para convidados da versão da VM 8.2 é HwThreadCountPerCore = 1. Quando esses convidados forem executados em um host do Windows Server 2019, eles serão tratados da seguinte maneira:
Se a VM tiver uma contagem de VP menor ou igual à contagem de núcleos LP, a VM será tratada como uma VM não SMT pelo agendador principal. Quando o VP convidado for executado em um único thread SMT, o thread SMT irmão do núcleo ficará ocioso. Isso não é ideal e resultará em perda geral de desempenho.
Se a VM tiver mais VPs do que núcleos LP, a VM será tratada como uma VM SMT pelo agendador principal. No entanto, a VM não observará outras indicações de que é uma VM SMT. Por exemplo, o uso da instrução CPUID ou das APIs do Windows para consultar a topologia da CPU pelo sistema operacional ou pelos aplicativos não indicará que o SMT está habilitado.
Quando uma VM existente é explicitamente atualizada de versões da VM anteriores para a versão 9.0 por meio da operação Update-VM, ela manterá seu valor atual de HwThreadCountPerCore. A VM não terá o SMT habilitado à força.
No Windows Server 2016, a Microsoft recomenda habilitar o SMT para VMs convidadas. Por padrão, as VMs criadas no Windows Server 2016 teriam o SMT desabilitado, ou seja, HwThreadCountPerCore é definido como 1, a menos que seja explicitamente alterado.
Observação
O Windows Server 2016 não dá suporte à configuração HwThreadCountPerCore como 0.
Gerenciando a configuração de SMT da máquina virtual
A configuração de SMT da máquina virtual convidada é definida conforme a VM. O administrador do host pode inspecionar e definir a configuração de SMT de uma VM e escolher dentre as seguintes opções:
Configurar VMs para serem executadas como habilitadas para SMT, herdando opcionalmente a topologia SMT do host automaticamente
Configurar VMs para serem executadas como não SMT
A configuração de SMT para uma VM é exibida nos painéis Resumo no console do Gerenciador do Hyper-V. A definição das configurações de SMT de uma VM pode ser feita usando as Configurações da VM ou o PowerShell.
Definindo as configurações de SMT da VM usando o PowerShell
Para definir as configurações de SMT para uma máquina virtual convidada, abra uma janela do PowerShell com permissões suficientes e digite:
Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>
Em que:
0 = Não há suporte à herança d a topologia SMT do host (não há suporte a essa configuração de HwThreadCountPerCore=0 no Windows Server 2016)
1 = Não SMT
Valores > 1 = o número desejado de threads SMT por núcleo. Não pode exceder o número de threads SMT físicos por núcleo.
Para ler as configurações de SMT para uma máquina virtual convidada, abra uma janela do PowerShell com permissões suficientes e digite:
(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore
Observe que as VMs convidadas configuradas com HwThreadCountPerCore = 0 indicam que o SMT será habilitado para o convidado e exporá o mesmo número de threads SMT ao convidado que estão no host de virtualização subjacente, normalmente 2.
As VMs convidadas podem observar alterações na topologia da CPU em cenários de mobilidade de VM
O sistema operacional e os aplicativos em uma VM podem ver alterações nas configurações de host e VM antes e depois de eventos do ciclo de vida da VM, como migração ao vivo ou operações de salvamento e restauração. Durante uma operação na qual o estado da VM é salvo e restaurado, a configuração HwThreadCountPerCore da VM e o valor realizado (ou seja, a combinação computada da configuração da VM e da configuração do host de origem) são migrados. A VM continuará em execução com essas configurações no host de destino. No ponto em que a VM foi desligada e reiniciou, é possível que o valor percebido observado pela VM seja alterado. Isso deve ser benigno, pois o software da camada de aplicativo e sistema operacional devem procurar informações de topologia da CPU como parte de seus fluxos normais de código de inicialização. No entanto, como essas sequências de inicialização de tempo de inicialização são ignoradas durante as operações de migração dinâmica ou de salvamento/restauração, as VMs que passam por essas transições de estado poderiam seguir o valor calculado originalmente até serem desligadas e reiniciadas.
Alertas sobre configurações de VM não ideais
Máquinas virtuais configuradas com mais VPs do que núcleos físicos no host resultam em uma configuração não ideal. O agendador de hipervisor tratará essas VMs como se tivessem reconhecimento de SMT. No entanto, o software do sistema operacional e do aplicativo na VM verá uma topologia de CPU mostrando que a SMT está desabilitada. Quando essa condição for detectada, o Processo de Trabalho do Hyper-V registrará em log um evento no host de virtualização avisando o administrador do host de que a configuração da VM não é ideal e recomendando que a SMT seja habilitada para a VM.
Como identificar VMs configuradas de forma não ideal
Você pode identificar VMs não SMT procurando no log do sistema no Visualizador de Eventos o ID de evento 3498 do Processo de Trabalho do Hyper-V, que será disparado para uma VM sempre que o número de VPs na VM for maior que a contagem de núcleos físicos. Os eventos do processo de trabalho podem ser obtidos do Visualizador de Eventos ou por meio do PowerShell.
Consultando o evento de VM do processo de trabalho do Hyper-V usando o PowerShell
Para consultar o ID de evento do processo de trabalho do Hyper-V 3498 usando o PowerShell, insira os comandos a seguir em um prompt do PowerShell.
Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}
Impactos da configuração de SMT convidada no uso de esclarecimentos de hipervisor para sistemas operacionais convidados
O hipervisor da Microsoft oferece vários esclarecimentos, ou dicas, que o sistema operacional em execução em uma VM convidada pode consultar e usar para disparar otimizações, como aquelas que podem beneficiar o desempenho ou melhorar o tratamento de várias condições na execução virtualizada. Um esclarecimento introduzido recentemente diz respeito ao tratamento do agendamento do processador virtual e ao uso de mitigações do sistema operacional para ataques do lado do canal que exploram a SMT.
Observação
A Microsoft recomenda que os administradores de host habilitem a SMT para VMs convidadas a fim de otimizar o desempenho da carga de trabalho.
Os detalhes desse esclarecimento de convidado são fornecidos abaixo; no entanto, a principal conclusão para os administradores de host de virtualização é que as máquinas virtuais devem ter HwThreadCountPerCore configurado para corresponder à configuração de SMT física do host. Isso permite que o hipervisor relate que não há compartilhamento de núcleo não arquitetônico. Portanto, qualquer sistema operacional convidado que dê suporte a otimizações que exijam o esclarecimento pode estar habilitado. No Windows Server 2019, crie outras VMs e deixe o valor padrão de HwThreadCountPerCore (0). VMs mais antigas migradas de hosts do Windows Server 2016 podem ser atualizadas para a versão de configuração do Windows Server 2019. Depois de fazer isso, a Microsoft recomenda definir HwThreadCountPerCore = 0. No Windows Server 2016, a Microsoft recomenda definir HwThreadCountPerCore para corresponder à configuração do host (normalmente 2).
Detalhes de esclarecimento de NoNonArchitecturalCoreSharing
Desde o Windows Server 2016, o hipervisor define um novo esclarecimento para descrever sua manipulação de agendamento e posicionamento de VP para o sistema operacional convidado. Esse esclarecimento é definido na Especificação Funcional de Nível Geral do Hipervisor v5.0c.
Hypervisor synthetic CPUID leaf CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] indica que um processador virtual nunca compartilhará um núcleo físico com outro processador virtual, exceto em caso de processadores virtuais relatados como threads SMT irmãos. Por exemplo, um VP convidado nunca será executado em um thread SMT junto com um VP raiz em execução simultaneamente em um thread SMT irmão no mesmo núcleo do processador. Essa condição só é possível na execução virtualizada e, portanto, representa um comportamento de SMT não arquitetônica que também tem sérias implicações de segurança. O sistema operacional convidado pode usar NoNonArchitecturalCoreSharing = 1 como uma indicação de que é seguro habilitar otimizações, o que pode ajudá-lo a evitar a sobrecarga de desempenho da configuração de STIBP.
Em determinadas configurações, o hipervisor não indicará que NoNonArchitecturalCoreSharing = 1. Por exemplo, se um host tiver a SMT habilitada e estiver configurado para usar o agendador clássico do hipervisor, NoNonArchitecturalCoreSharing será 0. Isso pode impedir que convidados habilitados habilitem determinadas otimizações. Portanto, a Microsoft recomenda que os administradores de host que usam SMT dependam do agendador principal do hipervisor e verifiquem se as máquinas virtuais estão configuradas para herdar sua configuração de SMT do host a fim de garantir o desempenho ideal da carga de trabalho.
Resumo
O cenário de ameaças à segurança continua evoluindo. Para garantir que nossos clientes estejam protegidos por padrão, a Microsoft está alterando a configuração padrão para o hipervisor e as máquinas virtuais a partir do Windows Server 2019 Hyper-V e fornecendo diretrizes e recomendações atualizadas para clientes que executam o Hyper-V do Windows Server 2016. Os administradores de host de virtualização devem:
Ler e entender as diretrizes fornecidas neste documento
Avaliar e ajustar cuidadosamente suas implantações de virtualização para garantir que elas atendam às metas de segurança, desempenho, densidade de virtualização e capacidade de resposta da carga de trabalho para seus requisitos exclusivos
Considerar configurar novamente os hosts Hyper-V do Windows Server 2016 existentes para aproveitar os benefícios de segurança sólidos oferecidos pelo agendador principal do hipervisor
Atualizar as VMs não SMT existentes para reduzir os impactos no desempenho das restrições de agendamento impostas pelo isolamento de VP que resolve vulnerabilidades de segurança de hardware