Acerca de la selección de tipos de programador de hipervisor Hyper-V
En este documento se describen los cambios importantes en el uso predeterminado de Hyper-V y el uso recomendado de los tipos de programador de hipervisor. Estos cambios afectan tanto a la seguridad del sistema como al rendimiento de la virtualización. Los administradores de host de virtualización deben revisar y comprender los cambios e implicaciones descritos en este documento, y evaluar cuidadosamente los impactos, las instrucciones de implementación sugeridas y los factores de riesgo implicados para comprender mejor cómo implementar y administrar hosts de Hyper-V frente al panorama de seguridad que cambia rápidamente.
Importante
Actualmente, una máquina virtual invitada malintencionada podría aprovechar las vulnerabilidades de seguridad de canal lateral conocidas detectadas en varias arquitecturas de procesador a través del comportamiento de programación del tipo de programador clásico del hipervisor heredado cuando se ejecuta en hosts con subprocesamiento múltiple simultáneo (SMT) habilitado. Si se aprovecha correctamente, una carga de trabajo malintencionada podría observar datos fuera de su límite de partición. Esta clase de ataques se puede mitigar configurando el hipervisor de Hyper-V para usar el tipo de programador principal del hipervisor y reconfigurando las máquinas virtuales invitadas. Con el programador principal, el hipervisor restringe los VP de una VM invitada para que se ejecuten en el mismo núcleo de procesador físico, por lo que aísla fuertemente la capacidad de la máquina virtual para acceder a los datos a los límites del núcleo físico en el que se ejecuta. Se trata de una mitigación muy eficaz frente a estos ataques de canal lateral, lo que impide que la máquina virtual observe cualquier artefacto de otras particiones, ya sea la raíz u otra partición de invitado. Por lo tanto, Microsoft está cambiando los valores de configuración predeterminados y recomendados para hosts de virtualización y máquinas virtuales invitadas.
Información previa
A partir de Windows Server 2016, Hyper-V admite varios métodos de programación y administración de procesadores virtuales, denominados tipos de programador de hipervisor. Puede encontrar una descripción detallada de todos los tipos de programador de hipervisor en Descripción y uso de tipos de programador de hipervisor de Hyper-V.
Nota
Los nuevos tipos de programador de hipervisor se introdujeron por primera vez con Windows Server 2016 y no están disponibles en versiones anteriores. Todas las versiones de Hyper-V anteriores a Windows Server 2016 solo admiten el programador clásico. La compatibilidad con el programador principal solo se publicó recientemente.
Acerca de los tipos de programador de hipervisor
Este artículo se centra específicamente en el uso del nuevo tipo de programador principal del hipervisor frente al programador “clásico” heredado, y cómo estos tipos de programador se cruzan con el uso del subprocesamiento múltiple simétrico o SMT. Es importante comprender las diferencias entre los programadores principales y clásicos y cómo cada uno de ellos coloca el trabajo de las máquinas virtuales invitadas en los procesadores del sistema subyacente.
El programador clásico
El programador clásico hace referencia al método de proporcionalidad equilibrada y Round Robin de programación de trabajo en procesadores virtuales (VP) en todo el sistema, incluidas los VP raíz, así como los VP que pertenecen a las VM invitadas. El programador clásico ha sido el tipo de programador predeterminado que se usa en todas las versiones de Hyper-V (hasta Windows Server 2019, como se describe aquí). Las características de rendimiento del programador clásico se entienden bien y el programador clásico se demuestra que admite de forma excesiva la suscripción de las cargas de trabajo, es decir, la suscripción excesiva de la relación VP:LP del host por un margen razonable (según los tipos de cargas de trabajo que se virtualizan, el uso general de recursos, etc.).
Cuando se ejecuta en un host de virtualización con SMT habilitado, el programador clásico programará los VP invitados desde cualquier máquina virtual de cada subproceso SMT que pertenezca a un núcleo de forma independiente. Por lo tanto, se pueden ejecutar máquinas virtuales diferentes en el mismo núcleo al mismo tiempo (una máquina virtual se ejecuta en un subproceso de un núcleo mientras otra máquina virtual se ejecuta en el otro subproceso).
El programador principal
El programador principal aprovecha las propiedades de SMT para proporcionar aislamiento de las cargas de trabajo invitadas, lo que afecta tanto a la seguridad como al rendimiento del sistema. El programador principal garantiza que los VP de una VM estén programados en subprocesos SMT del mismo nivel. Esto se hace simétricamente para que, si los LP están en grupos de dos, los VP se programan en grupos de dos y un núcleo de CPU del sistema nunca se comparte entre VM.
Mediante la programación de VP invitados en pares SMT subyacentes, el programador principal ofrece un límite de seguridad seguro para el aislamiento de la carga de trabajo y también se puede usar para reducir la variabilidad del rendimiento de las cargas de trabajo sensibles a la latencia.
Tenga en cuenta que cuando el VP está programado para una máquina virtual sin SMT habilitada, ese VP consumirá todo el núcleo cuando se ejecute y el subproceso SMT del mismo nivel del núcleo quedará inactivo. Esto es necesario para proporcionar el aislamiento de carga de trabajo correcto, pero afecta al rendimiento general del sistema, especialmente a medida que los VP del sistema se suscriben por encima de la suscripción, es decir, cuando la relación total VP:LP supera el 1:1. Por lo tanto, la ejecución de VM invitadas configuradas sin varios subprocesos por núcleo es una configuración subóptima.
Ventajas del uso del programador principal
El programador principal ofrece las siguientes ventajas:
Un límite de seguridad seguro para el aislamiento de la carga de trabajo de invitado: los VP invitados están restringidos a ejecutarse en pares de núcleo físico subyacentes, lo que reduce la vulnerabilidad a los ataques de snooping del canal lateral.
Reducción de la variabilidad de la carga de trabajo: la variabilidad del rendimiento de la carga de trabajo invitado se reduce significativamente, lo que ofrece una mayor coherencia de la carga de trabajo.
Uso de SMT en VM invitadas: el sistema operativo y las aplicaciones que se ejecutan en la máquina virtual invitada pueden usar interfaces de programación (API) y comportamiento de SMT para controlar y distribuir el trabajo entre subprocesos SMT, del mismo modo que cuando se ejecutan no virtualizados.
El programador principal se usa actualmente en hosts de virtualización de Azure, específicamente para aprovechar los límites de seguridad seguros y la variabilidad de carga de trabajo baja. Microsoft cree que el tipo de programador principal debe ser y seguirá siendo el tipo de programación de hipervisor predeterminado para la mayoría de los escenarios de virtualización. Por lo tanto, para asegurarse de que nuestros clientes son seguros de forma predeterminada, Microsoft está realizando este cambio para Windows Server 2019.
Impactos en el rendimiento del programador principal en las cargas de trabajo de invitado
Aunque es necesario para mitigar eficazmente ciertas clases de vulnerabilidades, el programador principal también puede reducir el rendimiento. Los clientes pueden ver una diferencia en las características de rendimiento con sus máquinas virtuales e impactos en la capacidad general de carga de trabajo de sus hosts de virtualización. En los casos en los que el programador principal debe ejecutar un VP que no sea SMT, solo se ejecuta una de las secuencias de instrucciones en el núcleo lógico subyacente, mientras que la otra debe dejarse inactiva. Esto limitará la capacidad total del host para las cargas de trabajo invitadas.
Estos impactos en el rendimiento se pueden minimizar siguiendo las instrucciones de implementación de este documento. Los administradores de host deben tener en cuenta cuidadosamente sus escenarios de implementación de virtualización específicos y equilibrar su tolerancia al riesgo de seguridad frente a la necesidad de una densidad máxima de carga de trabajo, una consolidación excesiva de los hosts de virtualización, etc.
Cambios en las configuraciones predeterminadas y recomendadas para Windows Server 2016 y Windows Server 2019
La implementación de hosts de Hyper-V con la posición de seguridad máxima requiere el uso del tipo de programador principal del hipervisor. Para garantizar que nuestros clientes son seguros de forma predeterminada, Microsoft está cambiando la siguiente configuración predeterminada y recomendada.
Nota
Aunque la compatibilidad interna del hipervisor con los tipos de programador se incluyó en la versión inicial de Windows Server 2016, Windows Server 1709 y Windows Server 1803, se requieren actualizaciones para tener acceso al control de configuración que permite seleccionar el tipo de programador de hipervisor. Consulte Descripción y uso de los tipos de programador de hipervisor de Hyper-V para obtener más información sobre estas actualizaciones.
Cambios en el host de virtualización
El hipervisor usará el programador principal de forma predeterminada a partir de Windows Server 2019.
Microsoft recomienda configurar el programador principal en Windows Server 2016. El tipo de programador principal del hipervisor se admite en Windows Server 2016, pero el valor predeterminado es el programador clásico. El programador principal es opcional y el administrador del host de Hyper-V debe habilitarlo explícitamente.
Cambios en la configuración de la máquina virtual
En Windows Server 2019, las nuevas máquinas virtuales creadas con la versión predeterminada de la máquina virtual 9.0 heredarán automáticamente las propiedades SMT (habilitadas o deshabilitadas) del host de virtualización. Es decir, si SMT está habilitado en el host físico, las máquinas virtuales recién creadas también tendrán habilitado SMT y heredarán la topología SMT del host de forma predeterminada, con la máquina virtual que tiene el mismo número de subprocesos de hardware por núcleo que el sistema subyacente. Esto se reflejará en la configuración de la máquina virtual con HwThreadCountPerCore = 0, donde 0 indica que la máquina virtual debe heredar la configuración de SMT del host.
Las máquinas virtuales existentes con una versión de máquina virtual de la versión 8.2 o anterior conservarán su configuración de procesador de máquina virtual original para HwThreadCountPerCore y el valor predeterminado para los invitados de la versión de máquina virtual 8.2 es HwThreadCountPerCore = 1. Cuando estos invitados se ejecuten en un host de Windows Server 2019, se tratarán de la siguiente manera:
Si la VM tiene un recuento de VP que es menor o igual que el recuento de núcleos de LP, el programador principal tratará la VM como una VM que no sea SMT. Cuando el VP invitado se ejecuta en un único subproceso SMT, el subproceso SMT relacionado del núcleo quedará inactivo. Esto no es óptimo y provocará una pérdida general del rendimiento.
Si la VM tiene más VP que núcleos LP, el programador principal tratará la VM como una VM SMT. Sin embargo, la máquina virtual no observará otras indicaciones de que es una máquina virtual SMT. Por ejemplo, el uso de la instrucción CPUID o las API de Windows para consultar la topología de CPU por parte del sistema operativo o las aplicaciones no indicará que SMT está habilitado.
Cuando una máquina virtual existente se actualiza explícitamente desde versiones de máquina virtual anteriores a la versión 9.0 a través de la operación Update-VM, la máquina virtual conservará su valor actual para HwThreadCountPerCore. La máquina virtual no tendrá habilitada la SMT.
En Windows Server 2016, Microsoft recomienda habilitar SMT para máquinas virtuales invitadas. De forma predeterminada, las máquinas virtuales creadas en Windows Server 2016 habrían deshabilitado SMT, es decir, HwThreadCountPerCore se establece en 1, a menos que se cambie explícitamente.
Nota
Windows Server 2016 no admite la configuración de HwThreadCountPerCore en 0.
Administración de la configuración de SMT de la máquina virtual
La configuración de SMT de la máquina virtual invitada se establece por VM. El administrador de host puede inspeccionar y configurar la configuración de SMT de una VM para seleccionar entre las siguientes opciones:
Configurar las máquinas virtuales para que se ejecuten como habilitadas para SMT; opcionalmente, hereda la topología de SMT del host automáticamente
Configurar VM para que se ejecuten como no SMT
La configuración de SMT para una VM se muestra en los paneles Resumen de la consola del Administrador de Hyper-V. La configuración de SMT de una VM se puede realizar mediante la configuración de la máquina virtual o PowerShell.
Configuración de los ajustes de SMT de VM mediante PowerShell
Para configurar los ajustes de SMT para una máquina virtual invitada, abra una ventana de PowerShell con permisos suficientes y escriba:
Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>
Donde:
0 = Heredar la topología SMT del host (esta configuración de HwThreadCountPerCore=0 no se admite en Windows Server 2016)
1 = No SMT
Valores > 1 = el número deseado de subprocesos SMT por núcleo. Puede que no supere el número de subprocesos SMT físicos por núcleo.
Para leer la configuración de SMT de una máquina virtual invitada, abra una ventana de PowerShell con permisos suficientes y escriba:
(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore
Tenga en cuenta que las máquinas virtuales invitadas configuradas con HwThreadCountPerCore = 0 indican que SMT se habilitará para el invitado y expondrá el mismo número de subprocesos SMT al invitado que están en el host de virtualización subyacente, normalmente 2.
Las VM invitadas pueden observar cambios en la topología de CPU en escenarios de movilidad de VM.
El sistema operativo y las aplicaciones de una VM pueden ver los cambios en la configuración del host y de la VM antes y después de los eventos de ciclo de vida de la VM, como la migración en vivo o las operaciones de guardado y restauración. Durante una operación en la que se guarda y restaura el estado de la máquina virtual, se migran la configuración HwThreadCountPerCore de la máquina virtual y el valor realizado (es decir, la combinación calculada de la configuración de la máquina virtual y la configuración del host de origen). La máquina virtual seguirá ejecutándose con esta configuración en el host de destino. En el momento en que la máquina virtual se apaga y se vuelve a iniciar, es posible que el valor realizado observado por la máquina virtual cambie. Este debe ser benigno, ya que el software del nivel de sistema operativo y de la aplicación debe buscar información de la topología de CPU como parte de sus flujos de código de inicio e inicialización normales. Sin embargo, dado que estas secuencias de inicialización de tiempo de arranque se omiten durante las operaciones de migración en vivo o de guardado o restauración, las máquinas virtuales que se someten a estas transiciones de estado podrían observar el valor calculado originalmente hasta que se apagan y se vuelven a iniciar.
Alertas relacionadas con configuraciones de VM no óptimas
Las máquinas virtuales configuradas con más VP que núcleos físicos en el host dan lugar a una configuración no óptima. El programador del hipervisor tratará estas VM como si fueran compatibles con SMT. Sin embargo, el sistema operativo y el software de la aplicación en la máquina virtual aparecerán una topología de CPU en la que se muestra que SMT está deshabilitada. Cuando se detecta esta condición, el proceso de trabajo de Hyper-V registrará un evento en el host de virtualización que advierte al administrador del host de que la configuración de la máquina virtual no es óptima y se recomienda habilitar SMT para la máquina virtual.
Identificación de VM no configuradas de forma óptima
Puede identificar VM que no son SMT examinando el registro del sistema en Visor de eventos para el id. de evento de proceso de trabajo de Hyper-V 3498, que se desencadenará para una VM siempre que el número de VP de la VM sea mayor que el número de núcleos físicos. Los eventos de proceso de trabajo se pueden obtener del Visor de eventos o a través de PowerShell.
Consulta del evento de VM de proceso de trabajo de Hyper-V mediante PowerShell
Para consultar el id.de evento de proceso de trabajo de Hyper-V 3498 mediante PowerShell, escriba los siguientes comandos desde un símbolo del sistema de PowerShell.
Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}
Impactos de la configuración de la SMT invitada en el uso de iluminaciones de hipervisor para sistemas operativos invitados
El hipervisor de Microsoft ofrece varias iluminaciones, o sugerencias, que el sistema operativo que se ejecuta en una VM invitada puede consultar y usar para desencadenar optimizaciones, como aquellas que podrían beneficiar el rendimiento o mejorar el control de varias condiciones cuando se ejecuta de forma virtualizada. Recientemente se ha introducido una iluminación que afecta al control de la programación del procesador virtual y al uso de mitigaciones del sistema operativo para ataques de canal lateral que explotan SMT.
Nota
Microsoft recomienda que los administradores host habiliten SMT para las máquinas virtuales invitadas para optimizar el rendimiento de la carga de trabajo.
A continuación, se proporcionan los detalles de esta iluminación de invitado, pero la clave para los administradores de host de virtualización es que las máquinas virtuales deben tener HwThreadCountPerCore configurado para que coincida con la configuración física de SMT del host. Esto permite que el hipervisor notifique que no hay ningún uso compartido de núcleos no arquitectónicos. Por lo tanto, cualquier sistema operativo invitado que admita optimizaciones que requieran la iluminación se puede habilitar. En Windows Server 2019, cree nuevas máquinas virtuales y deje el valor predeterminado de HwThreadCountPerCore (0). Las máquinas virtuales anteriores migradas desde hosts de Windows Server 2016 se pueden actualizar a la versión de configuración de Windows Server 2019. Después de hacerlo, Microsoft recomienda establecer HwThreadCountPerCore = 0. En Windows Server 2016, Microsoft recomienda establecer HwThreadCountPerCore para que coincida con la configuración del host (normalmente 2).
Detalles de iluminación NoNonArchitecturalCoreSharing
A partir de Windows Server 2016, el hipervisor define una nueva iluminación para describir su control de la programación y la colocación de VP en el sistema operativo invitado. Esta iluminación se define en la especificación funcional de nivel superior del hipervisor v5.0c.
La hoja de CPUID sintética de hipervisor CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] indica que un procesador virtual nunca compartirá un núcleo físico con otro procesador virtual, excepto los procesadores virtuales que se notifican como subprocesos SMT del mismo nivel. Por ejemplo, un VP invitado nunca se ejecutará en un subproceso SMT junto con un VP raíz que se ejecuta simultáneamente en un subproceso SMT relacionado en el mismo núcleo del procesador. Esta condición solo es posible cuando se ejecuta de forma virtualizada, por lo que representa un comportamiento de SMT no arquitectónico que también tiene graves implicaciones de seguridad. El sistema operativo invitado puede usar NoNonArchitecturalCoreSharing = 1 como indicación de que es seguro habilitar optimizaciones, lo que puede ayudar a evitar la sobrecarga de rendimiento de establecer STIBP.
En determinadas configuraciones, el hipervisor no indicará que NoNonArchitecturalCoreSharing = 1. Por ejemplo, si un host tiene SMT habilitado y está configurado para usar el programador clásico del hipervisor, NoNonArchitecturalCoreSharing será 0. Esto puede impedir que los invitados habilitados habiliten determinadas optimizaciones. Por lo tanto, Microsoft recomienda que los administradores de host que usan SMT se basen en el programador principal del hipervisor y asegúrese de que las máquinas virtuales están configuradas para heredar su configuración de SMT del host para garantizar un rendimiento óptimo de la carga de trabajo.
Resumen
El panorama de amenazas de seguridad sigue evolucionando. Para asegurarse de que nuestros clientes son seguros de forma predeterminada, Microsoft cambia la configuración predeterminada del hipervisor y las máquinas virtuales a partir de Windows Server 2019 Hyper-V y proporciona instrucciones y recomendaciones actualizadas para los clientes que ejecutan Windows Server 2016 Hyper-V. Los administradores de host de virtualización deben:
Leer y comprender las instrucciones proporcionadas en este documento.
Evaluar y ajustar cuidadosamente sus implementaciones de virtualización para asegurarse de que cumplen los objetivos de seguridad, rendimiento, densidad de virtualización y capacidad de respuesta de la carga de trabajo para sus requisitos únicos.
Considerar la posibilidad de volver a configurar los hosts existentes de Windows Server 2016 Hyper-V para aprovechar las ventajas de seguridad sólidas que ofrece el programador principal del hipervisor.
Actualizar las VM existentes que no son SMT para reducir el impacto en el rendimiento de las restricciones de programación impuestas por el aislamiento de VP que soluciona las vulnerabilidades de seguridad de hardware.