Partager via

À propos de la sélection du type de planificateur d’hyperviseur Hyper-V

Ce document décrit les modifications importantes apportées à la valeur par défaut d’Hyper-V et l’utilisation recommandée des types de planificateurs d’hyperviseur. Ces changements ont un impact sur la sécurité du système et les performances de virtualisation. Les administrateurs de l’hôte de virtualisation doivent examiner et comprendre les modifications et les implications décrites dans ce document, et évaluer soigneusement les impacts, les conseils de déploiement suggérés et les facteurs de risque impliqués pour mieux comprendre comment déployer et gérer les hôtes Hyper-V face à l’évolution rapide du paysage de la sécurité.

Important

Les vulnérabilités de sécurité de canal latéral actuellement connues dans plusieurs architectures de processeur peuvent être exploitées par une machine virtuelle invitée malveillante via le comportement de planification du type de planificateur classique d’hyperviseur hérité lors de l’exécution sur des hôtes avec le multithreading simultané (SMT) activé. Si elle est correctement exploitée, une charge de travail malveillante peut observer des données en dehors de sa limite de partition. Cette classe d’attaques peut être atténuée en configurant l’hyperviseur Hyper-V pour utiliser le type de planificateur de cœurs de l’hyperviseur et en reconfigurant les machines virtuelles invitées. Avec le planificateur de cœurs, l’hyperviseur empêche les machines virtuelles d’une machine virtuelle invitée de s’exécuter sur le même cœur de processeur physique, ce qui restreint la capacité de la machine virtuelle à accéder aux données aux limites du cœur physique sur lequel elle s’exécute. Il s’agit d’une atténuation très efficace contre ces attaques par canal latéral, en empêchant la machine virtuelle d’observer les artefacts d’autres partitions, qu’il s’agisse de la partition racine ou d’une autre partition invitée. Par conséquent, Microsoft modifie les paramètres de configuration par défaut et recommandés pour les hôtes de virtualisation et les machines virtuelles invitées.

Contexte

À compter de Windows Server 2016, Hyper-V prend en charge plusieurs méthodes de planification et de gestion des processeurs virtuels, appelées types de planificateurs d’hyperviseur. Vous trouverez une description détaillée de tous les types de planificateurs d’hyperviseur dans Compréhension et utilisation des types de planificateur d’hyperviseur Hyper-V.

Notes

Les nouveaux types de planificateurs d’hyperviseurs ont été introduits pour la première fois avec Windows Server 2016 et ne sont pas disponibles dans les versions antérieures. Toutes les versions d’Hyper-V antérieures à Windows Server 2016 prennent uniquement en charge le planificateur classique. La prise en charge du planificateur de cœurs n’a été publiée que récemment.

À propos des types de planificateur d’hyperviseur

Cet article se concentre spécifiquement sur l’utilisation du nouveau type de planificateur de cœurs d’hyperviseur par rapport au planificateur « classique » hérité, et sur la façon dont ces types de planificateurs se croisent avec l’utilisation du multithreading symétrique, ou SMT. Il est important de comprendre les différences entre les planificateurs de cœurs et classiques, ainsi que la façon dont chacun place le travail à partir des machines virtuelles invitées sur les processeurs système sous-jacents.

Planificateur classique

Le planificateur classique fait référence à la méthode de tourniquet (round robin) équitable de planification du travail sur les processeurs virtuels (VP) dans le système, y compris les VP racines ainsi que les VP appartenant à des machines virtuelles invitées. Le planificateur classique est le type de planificateur par défaut utilisé sur toutes les versions d’Hyper-V (jusqu’à Windows Server 2019, comme décrit ici). Les caractéristiques de performances du planificateur classique sont bien comprises, et le planificateur classique prend en charge de manière efficace le surabonnement des charges de travail, c’est-à-dire le surabonnement du ratio VP/LP de l’hôte dans une marge raisonnable (selon les types de charges de travail virtualisées, l’utilisation globale des ressources, etc.).

Lors de l’exécution sur un hôte de virtualisation avec SMT activé, le planificateur classique planifie les machines virtuelles invitées à partir de n’importe quelle machine virtuelle sur chaque thread SMT appartenant à un cœur indépendamment. Par conséquent, différentes machines virtuelles peuvent s’exécuter sur le même cœur en même temps (une machine virtuelle s’exécute sur un thread d’un cœur tandis qu’une autre machine virtuelle s’exécute sur l’autre thread).

Planificateur de cœurs

Le planificateur de cœurs tire parti des propriétés de SMT pour fournir une isolation des charges de travail invitées, ce qui a un impact à la fois sur la sécurité et les performances du système. Le planificateur de cœurs garantit que les machines virtuelles d’une machine virtuelle sont planifiées sur des threads SMT frères. Cela s’effectue symétriquement, de sorte que si les fournisseurs de services se trouvent dans des groupes de deux, les machines virtuelles sont planifiées en groupes de deux, et un cœur de processeur système n’est jamais partagé entre les machines virtuelles.

En planifiant des adresses virtuelles invitées sur des paires SMT sous-jacentes, le planificateur de cœurs offre une limite de sécurité forte pour l’isolation des charges de travail, et peut également être utilisé pour réduire la variabilité des performances pour les charges de travail sensibles à la latence.

Notez que lorsque le VP est planifié pour une machine virtuelle sans SMT activé, ce VP consomme l’intégralité du cœur lorsqu’il s’exécute, et le thread SMT frère du cœur est laissé inactif. Cela est nécessaire pour fournir une isolation correcte de la charge de travail, mais cela a un impact sur les performances globales du système, d’autant plus que les fournisseurs de services système deviennent surabonnés, c’est-à-dire lorsque le ratio VP:LP total dépasse 1:1. Par conséquent, l’exécution de machines virtuelles invitées configurées sans plusieurs threads par cœur n’est pas optimale.

Avantages de l’utilisation du planificateur de cœurs

Le planificateur de cœurs offre les avantages suivants :

  • Limite de sécurité forte pour l’isolation des charges de travail invitées : les machines virtuelles invitées sont contraintes de s’exécuter sur des paires de cœurs physiques sous-jacentes, ce qui réduit la vulnérabilité aux attaques d’espionnage par canal latéral.

  • Variabilité réduite de la charge de travail : la variabilité du débit de la charge de travail invité est considérablement réduite, ce qui offre une plus grande cohérence de la charge de travail.

  • Utilisation de SMT dans les machines virtuelles invitées : le système d’exploitation et les applications s’exécutant sur la machine virtuelle invitée peuvent utiliser le comportement et les interfaces de programmation (API) SMT pour contrôler et distribuer le travail entre les threads SMT, comme ils le feraient lors d’une exécution non virtualisée.

Le planificateur de cœurs est actuellement utilisé sur les hôtes de virtualisation Azure, en particulier pour tirer parti de la limite de sécurité forte et de la faible variabilité des charges de travail. Microsoft estime que le type de planificateur de cœurs doit être et continuera d’être le type de planification d’hyperviseur par défaut pour la majorité des scénarios de virtualisation. Par conséquent, pour garantir la sécurité de nos clients par défaut, Microsoft apporte cette modification pour Windows Server 2019 maintenant.

Impact sur les performances du planificateur de cœurs sur les charges de travail invitées

Bien qu’il soit nécessaire d’atténuer efficacement certaines classes de vulnérabilités, le planificateur de cœurs peut également réduire les performances. Les clients pourraient observer une différence dans les caractéristiques de performances de leurs machines virtuelles et les impacts sur la capacité de charge de travail globale de leurs hôtes de virtualisation. Dans les cas où le planificateur de cœurs doit exécuter un VP non SMT, un seul des flux d’instructions dans le cœur logique sous-jacent s’exécute, tandis que l’autre doit être laissé inactif. Cela limite la capacité totale de l’hôte pour les charges de travail invitées.

Ces impacts sur les performances peuvent être réduits en suivant les instructions de déploiement de ce document. Les administrateurs hôtes doivent examiner attentivement leurs scénarios de déploiement de virtualisation spécifiques et équilibrer leur tolérance pour les risques de sécurité et la nécessité d’une densité de charge de travail maximale, le risque de consolidation excessive des hôtes de virtualisation, etc.

Le déploiement d’hôtes Hyper-V avec une posture de sécurité maximale nécessite l’utilisation du type de planificateur de cœurs de l’hyperviseur. Pour garantir la sécurité de nos clients par défaut, Microsoft modifie les paramètres par défaut et recommandés suivants.

Notes

Bien que la prise en charge interne de l’hyperviseur pour les types de planificateurs ait été incluse dans la version initiale de Windows Server 2016, Windows Server 1709 et Windows Server 1803, des mises à jour sont nécessaires pour accéder au contrôle de configuration qui permet de sélectionner le type de planificateur d’hyperviseur. Pour plus d’informations sur ces mises à jour, consultez Compréhension et utilisation des types de planificateur d’hyperviseur Hyper-V.

Modifications de l’hôte de virtualisation

  • L’hyperviseur utilise le planificateur de cœurs par défaut à compter de Windows Server 2019.

  • Microsoft recommande la configuration du planificateur de cœurs sur Windows Server 2016. Le type de planificateur de cœurs de l’hyperviseur est pris en charge dans Windows Server 2016, mais le planificateur classique est utilisé par défaut. Le planificateur de cœurs est facultatif et doit être explicitement activé par l’administrateur hôte Hyper-V.

Modifications de configuration de la machine virtuelle

  • Sur Windows Server 2019, les nouvelles machines virtuelles créées à l’aide de la machine virtuelle version 9.0 par défaut héritent automatiquement des propriétés SMT (activées ou désactivées) de l’hôte de virtualisation. Autrement dit, si SMT est activé sur l’hôte physique, les machines virtuelles nouvellement créées auront également SMT activé et hériteront de la topologie SMT de l’hôte par défaut, la machine virtuelle ayant le même nombre de threads matériels par cœur que le système sous-jacent. Cela se reflète dans la configuration de la machine virtuelle avec HwThreadCountPerCore = 0, où 0 indique que la machine virtuelle doit hériter des paramètres SMT de l’hôte.

  • Les machines virtuelles existantes version 8.2 ou antérieure conservent leur paramètre de processeur de machine virtuelle d’origine pour HwThreadCountPerCore, et la valeur par défaut pour les machines virtuelles invitées version 8.2 est HwThreadCountPerCore = 1. Lorsque ces invités s’exécutent sur un hôte Windows Server 2019, ils sont traités comme suit :

    1. Si la machine virtuelle a un nombre de VP inférieur ou égal au nombre de cœurs LP, la machine virtuelle est traitée comme une machine virtuelle non SMT par le planificateur de cœurs. Lorsque le VP invité s’exécute sur un seul thread SMT, le thread SMT frère du cœur est inactif. Cela n’est pas optimal et entraîne une réduction globale des performances.

    2. Si la machine virtuelle a plus de VP que de cœurs LP, la machine virtuelle est traitée comme une machine virtuelle SMT par le planificateur de cœurs. Toutefois, la machine virtuelle n’observe pas d’autres indications indiquant qu’il s’agit d’une machine virtuelle SMT. Par exemple, l’utilisation de l’instruction CPUID ou des API Windows pour interroger la topologie du processeur par le système d’exploitation ou les applications n’indique pas que SMT est activé.

  • Lorsqu’une machine virtuelle existante est explicitement mise à jour d’une version antérieure vers la version 9.0 via l’opération Update-VM, la machine virtuelle conserve sa valeur actuelle pour HwThreadCountPerCore. SMT n’est pas activé de force sur la machine virtuelle.

  • Sur Windows Server 2016, Microsoft recommande d’activer SMT pour les machines virtuelles invitées. Par défaut, les machines virtuelles créées sur Windows Server 2016 ont SMT désactivé, c’est-à-dire que HwThreadCountPerCore a la valeur 1, sauf modification explicite.

Notes

Windows Server 2016 ne prend pas en charge la définition de HwThreadCountPerCore sur 0.

Gestion de la configuration SMT de machine virtuelle

La configuration SMT de la machine virtuelle invitée est définie pour chaque machine virtuelle. L’administrateur hôte peut inspecter et configurer la configuration SMT d’une machine virtuelle pour choisir parmi les options suivantes :

  1. Configurer des machines virtuelles pour qu’elles s’exécutent comme machines SMT, en héritant automatiquement de la topologie SMT hôte

  2. Configurer des machines virtuelles pour qu’elles s’exécutent en tant que machines non SMT

La configuration de SMT pour une machine virtuelle s’affiche dans les volets Résumé de la console du Gestionnaire Hyper-V. La configuration des paramètres SMT d’une machine virtuelle peut être effectuée à l’aide des paramètres de machine virtuelle ou de PowerShell.

Configuration des paramètres SMT de machine virtuelle à l’aide de PowerShell

Pour configurer les paramètres SMT d’une machine virtuelle invitée, ouvrez une fenêtre PowerShell avec des autorisations suffisantes, puis tapez :

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

Où :

  • 0 = Hériter de la topologie SMT de l’hôte (ce paramètre de HwThreadCountPerCore=0 n’est pas pris en charge sur Windows Server 2016)

  • 1 = Non SMT

  • Valeurs > 1 = le nombre souhaité de threads SMT par cœur. Ne peut pas dépasser le nombre de threads SMT physiques par cœur.

Pour lire les paramètres SMT d’une machine virtuelle invitée, ouvrez une fenêtre PowerShell avec des autorisations suffisantes, puis tapez :

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

Notez que les machines virtuelles invitées configurées avec HwThreadCountPerCore = 0 indiquent que SMT sera activé pour l’invité et exposera le même nombre de threads SMT à l’invité que sur l’hôte de virtualisation sous-jacent, généralement 2.

Les machines virtuelles invitées pourraient observer des modifications de topologie du processeur dans les scénarios de mobilité des machines virtuelles

Le système d’exploitation et les applications d’une machine virtuelle pourraient observer des modifications apportées aux paramètres de l’hôte et de la machine virtuelle avant et après les événements de cycle de vie de la machine virtuelle, comme la migration dynamique ou les opérations d’enregistrement et de restauration. Lors d’une opération dans laquelle l’état de la machine virtuelle est enregistré et restauré, le paramètre HwThreadCountPerCore de la machine virtuelle et la valeur réalisée (c’est-à-dire la combinaison calculée du paramètre de la machine virtuelle et de la configuration de l’hôte source) sont migrés. La machine virtuelle continue de s’exécuter avec ces paramètres sur l’hôte de destination. Au moment où la machine virtuelle est arrêtée et redémarrée, il est possible que la valeur réalisée observée par la machine virtuelle change. Cela devrait être bénin, car les logiciels de la couche système d’exploitation et application doivent rechercher des informations de topologie du processeur dans le cadre de leurs flux de code de démarrage et d’initialisation normaux. Toutefois, étant donné que ces séquences d’initialisation au démarrage sont ignorées pendant les opérations de migration dynamique ou d’enregistrement/restauration, les machines virtuelles qui subissent ces transitions d’état peuvent observer la valeur réalisée calculée à l’origine jusqu’à ce qu’elles soient arrêtées et redémarrées.

Alertes concernant les configurations de machine virtuelle non optimales

Les machines virtuelles configurées avec plus de VP qu’il y a de cœurs physiques sur l’hôte entraînent une configuration non optimale. Le planificateur de l’hyperviseur traite ces machines virtuelles comme si elles prenaient en charge SMT. Toutefois, le système d’exploitation et les logiciels d’application dans la machine virtuelle se verront présenter une topologie d’UC indiquant que SMT est désactivé. Lorsque cette condition est détectée, le processus Worker Hyper-V enregistre un événement sur l’hôte de virtualisation, ce qui avertit l’administrateur hôte que la configuration de la machine virtuelle n’est pas optimale et recommande d’activer SMT pour la machine virtuelle.

Comment identifier les machines virtuelles configurées de manière non optimale

Vous pouvez identifier les machines virtuelles non SMT en examinant le journal système dans l’observateur d’événements pour l’ID d’événement 3498 du processus Worker Hyper-V, qui sera déclenché pour une machine virtuelle chaque fois que le nombre de VP dans la machine virtuelle est supérieur au nombre de cœurs physiques. Les événements de processus Worker peuvent être obtenus à partir de l’observateur d’événements ou via PowerShell.

Interrogation de l’événement de machine virtuelle du processus Worker Hyper-V à l’aide de PowerShell

Pour interroger l’ID d’événement de processus Worker Hyper-V 3498 à l’aide de PowerShell, entrez les commandes suivantes à partir d’une invite PowerShell.

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}

Impacts de la configuration SMT invitée sur l’utilisation des éclairages d’hyperviseur pour les systèmes d’exploitation invités

L’hyperviseur Microsoft offre plusieurs éclairages, ou conseils, que le système d’exploitation s’exécutant dans une machine virtuelle invitée peut interroger et utiliser pour déclencher des optimisations, comme celles qui peuvent améliorer les performances ou la gestion de diverses conditions lors de l’exécution virtualisée. Un éclairage récemment introduit concerne la gestion de la planification des processeurs virtuels et l’utilisation des atténuations du système d’exploitation pour les attaques par canal latéral qui exploitent SMT.

Notes

Microsoft recommande aux administrateurs hôtes d’activer SMT pour les machines virtuelles invitées afin d’optimiser les performances des charges de travail.

Les détails de cet éclairage invité sont fournis ci-dessous, mais le point à retenir pour les administrateurs de l’hôte de virtualisation est que les machines virtuelles doivent avoir HwThreadCountPerCore configuré pour correspondre à la configuration SMT physique de l’hôte. Cela permet à l’hyperviseur de signaler qu’il n’y a pas de partage de cœur non architectural. Par conséquent, tout système d’exploitation invité prenant en charge les optimisations qui nécessitent l’illumination peut être activé. Sur Windows Server 2019, créez des machines virtuelles et conservez la valeur par défaut HwThreadCountPerCore (0). Les machines virtuelles plus anciennes migrées à partir d’hôtes Windows Server 2016 peuvent être mises à jour vers la version de configuration de Windows Server 2019. Après cela, Microsoft recommande de définir HwThreadCountPerCore = 0. Sur Windows Server 2016, Microsoft recommande de définir HwThreadCountPerCore pour qu’il corresponde à la configuration de l’hôte (généralement 2).

Détails de l’éclairage NoNonArchitecturalCoreSharing

À partir de Windows Server 2016, l’hyperviseur définit un nouvel éclairage pour décrire sa gestion de la planification et du placement de VP sur le système d’exploitation invité. Cet éclairage est défini dans la Spécification fonctionnelle générale de l’hyperviseur v5.0c.

La feuille CPUID synthétique d’hyperviseur CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] indique qu’un processeur virtuel ne partagera jamais un cœur physique avec un autre processeur virtuel, à l’exception des processeurs virtuels qui sont signalés en tant que threads SMT frères. Par exemple, un VP invité ne s’exécutera jamais sur un thread SMT parallèlement à un VP racine s’exécutant simultanément sur un thread SMT frère sur le même cœur de processeur. Cette condition n’est possible que lors de l’exécution virtualisée, et représente donc un comportement SMT non architectural qui a également de sérieuses implications en matière de sécurité. Le système d’exploitation invité peut utiliser NoNonArchitecturalCoreSharing = 1 comme indication qu’il est sûr d’activer les optimisations, ce qui peut l’aider à éviter la surcharge de performances liée à la définition de STIBP.

Dans certaines configurations, l’hyperviseur n’indique pas NoNonArchitecturalCoreSharing = 1. Par exemple, si SMT est activé sur un hôte et qu’il est configuré pour utiliser le planificateur classique de l’hyperviseur, NoNonArchitecturalCoreSharing aura la valeur 0. Cela peut empêcher les invités éclairés d’activer certaines optimisations. Par conséquent, Microsoft recommande aux administrateurs hôtes qui utilisent SMT de s’appuyer sur le planificateur de cœurs de l’hyperviseur et de s’assurer que les machines virtuelles sont configurées pour hériter de leur configuration SMT de l’hôte afin de garantir des performances de charge de travail optimales.

Résumé

Le paysage des menaces de sécurité continue d’évoluer. Pour garantir la sécurité de nos clients par défaut, Microsoft modifie la configuration par défaut de l’hyperviseur et des machines virtuelles à partir de Windows Server 2019 Hyper-V, et fournit des conseils et des recommandations à jour aux clients exécutant Windows Server 2016 Hyper-V. Les administrateurs de l’hôte de virtualisation doivent :

  • Lire et comprendre les conseils fournis dans ce document

  • Évaluer et ajuster soigneusement leurs déploiements de virtualisation pour s’assurer qu’ils répondent aux objectifs de sécurité, de performances, de densité de virtualisation et de réactivité de charge de travail pour leurs besoins uniques

  • Envisager de configurer les hôtes Hyper-V Windows Server 2016 existants pour tirer parti des avantages de sécurité renforcée offerts par le planificateur de cœurs de l’hyperviseur

  • Mettre à jour les machines virtuelles non SMT existantes pour réduire les impacts sur les performances des contraintes de planification imposées par l’isolation de VP qui corrigent les vulnérabilités de sécurité matérielle