Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique décrit les problèmes de sécurité potentiels liés à l’allocation de mémoire partagée à partir d’une machine virtuelle pour les mémoires tampons de réception de la file d’attente de machines virtuelles (VMQ). La rubrique comprend les sections suivantes :
Vue d’ensemble des problèmes de sécurité liés à la mémoire partagée de la machine virtuelle
Comment Windows Server 2008 R2 résout le problème de sécurité
Comment Windows Server 2012 et versions ultérieures résolvent le problème de sécurité
Note Dans Hyper-V, une partition enfant est également appelée machine virtuelle.
Vue d’ensemble des problèmes de sécurité liés à la mémoire partagée de la machine virtuelle
Les machines virtuelles ne sont pas des entités logicielles approuvées. Autrement dit, une machine virtuelle malveillante ne doit pas pouvoir interférer avec d’autres machines virtuelles ou le système d’exploitation de gestion qui s’exécute dans la partition parente Hyper-V. Cette section fournit des informations générales et des exigences pour vous assurer que les enregistreurs de pilotes comprennent les problèmes de sécurité et les exigences de sécurité vmQ pour la mémoire partagée. Pour plus d’informations sur la mémoire partagée, consultez la rubrique Allocation de ressources de mémoire partagée dans la section Écriture de pilotes VMQ .
Dans l’environnement virtualisé, la mémoire partagée de la machine virtuelle peut être vue ou modifiée par la machine virtuelle. Toutefois, l’affichage ou la modification des données associées à d’autres machines virtuelles n’est pas autorisé. Les machines virtuelles ne sont pas autorisées à accéder à l'espace d'adressage de l'exploitation du système de gestion.
La partie en-tête des paquets reçus doit être protégée. Une machine virtuelle n’est pas autorisée à affecter le comportement du commutateur extensible Hyper-V dans un fournisseur de services virtuels réseau( VSP). Par conséquent, le filtrage VLAN (VIRTUAL LAN) doit se produire avant que la carte réseau utilise DMA pour transférer les données vers la mémoire partagée de la machine virtuelle. En outre, l’apprentissage de l’adresse MAC (Media Access Control) du commutateur ne peut pas être affectée.
Si le port de commutateur extensible Hyper-V connecté à une machine virtuelle a un identificateur VLAN associé, l’ordinateur hôte doit s’assurer que l’adresse MAC de destination et l’identificateur de réseau local virtuel du frame entrant correspondent à ces attributs respectifs du port avant que l’hôte transfère le paquet à la carte réseau virtuelle de la machine virtuelle. Si l’identificateur de réseau local virtuel de l’image ne correspond pas à l’identificateur de réseau local virtuel du port, le paquet est supprimé. Lorsque les mémoires tampons de réception d’une carte réseau virtuelle sont allouées à partir de la mémoire hôte, l’hôte peut vérifier l’identificateur du réseau local virtuel et supprimer le frame si nécessaire avant de rendre le contenu de l’image visible par la machine virtuelle cible. Si le frame n’est pas copié dans l’espace d’adressage d’une machine virtuelle, il n’est pas accessible par cette machine virtuelle.
Toutefois, lorsque VMQ est configuré pour utiliser la mémoire partagée, la carte réseau utilise DMA pour transférer des trames entrantes directement vers l’espace d’adressage de la machine virtuelle. Ce transfert introduit un problème de sécurité dans lequel une machine virtuelle peut examiner le contenu des images reçues sans attendre que le commutateur extensible applique le filtrage VLAN requis.
Comment Windows Server 2008 R2 résout le problème de sécurité
Dans Windows Server 2008 R2, avant que le VSP configure une file d’attente de machine virtuelle pour utiliser la mémoire partagée allouée à partir de l’espace d’adressage de machine virtuelle, elle utilise le test de filtrage suivant pour la file d’attente.
(MAC address == x) && (VLAN identifier == n)
Si le matériel de carte réseau peut prendre en charge ce test avant le transfert DMA vers les mémoires tampons de réception, la carte réseau peut supprimer des trames avec des identificateurs VLAN non valides ou les envoyer à la file d’attente par défaut afin qu’elles puissent être filtrées par le commutateur extensible. Si le pilote miniport réussit dans une requête pour définir un filtre avec ce test sur une file d’attente, le commutateur extensible peut utiliser la mémoire partagée de la machine virtuelle pour cette file d’attente. Toutefois, si le matériel de carte réseau n’est pas capable de filtrer les images en fonction de l’adresse MAC de destination et de l’identificateur VLAN, le commutateur extensible utilise la mémoire partagée de l’hôte pour cette file d’attente.
Le commutateur extensible inspecte l’adresse MAC source des trames reçues pour configurer les informations de routage pour les trames de transmission, c’est-à-dire qu’il est similaire à un commutateur d’apprentissage physique. Il est possible d’installer des pilotes de filtre de pare-feu dans la pile hôte ; par exemple, au-dessus du pilote miniport pour le matériel de la carte réseau et sous le pilote de commutateur extensible. Les pilotes de filtrage de pare-feu peuvent accéder aux données dans une trame reçue avant le commutateur virtuel extensible. Si l’intégralité de la mémoire tampon de réception pour chaque image est allouée à partir de l’espace d’adressage de machine virtuelle, une machine virtuelle malveillante peut accéder à des parties de la trame qui seraient examinées par un pilote de filtre ou le commutateur extensible qui s’exécute dans l’hôte.
Pour résoudre ce problème de sécurité, lors de l’utilisation de la mémoire partagée de la machine virtuelle pour une file d’attente de machines virtuelles, la carte réseau doit fractionner le paquet à un décalage d’octets d'au moins la taille de l'anticipation, qui est une valeur fixe prédéterminée. Toutes les données d'anticipation, c'est-à-dire les données avant le décalage d'octet pour la taille d'anticipation, doivent être transférées avec DMA vers la mémoire partagée allouée aux données d'anticipation. Les données post-lookahead (le reste de la charge utile de trame) doivent être transférées par DMA vers la mémoire partagée allouée pour les données post-lookahead.
L’illustration suivante montre les relations pour les structures de données réseau lorsque les données entrantes sont fractionnées en tampons de mémoire partagée de lookahead et de post-lookahead.
Les exigences récapitulatives pour la mémoire partagée VMQ sont les suivantes :
Une carte réseau peut fractionner une trame reçue à une limite de l'en-tête de réseau supérieure à la taille d'anticipation. Toutefois, lorsqu'elles sont demandées par NDIS et sans exception, toutes les trames reçues et assignées à une VMQ doivent être fractionnées à la limite de taille anticipée demandée par NDIS ou au-delà.
Les données de lookahead doivent être transférées avec DMA vers la mémoire partagée allouée par le pilote miniport. Le pilote miniport doit spécifier lors de l'appel d'allocation que la mémoire sera utilisée pour les données de lecture anticipée.
Les données post-lookahead doivent être transférées avec DMA vers la mémoire partagée allouée par le pilote miniport. Le pilote miniport doit spécifier dans l’appel d’allocation que la mémoire sera utilisée pour les données post-lookahead.
Les pilotes miniport ne doivent pas dépendre de l’espace d’adressage utilisé par NDIS pour effectuer la demande d’allocation de mémoire partagée. Autrement dit, l’espace d’adressage de mémoire partagée pour les données lookahead ou post-lookahead est spécifique à l’implémentation. Dans de nombreux cas, NDIS ou le commutateur extensible peut satisfaire toutes les demandes, y compris celles destinées à une utilisation après anticipation, à partir de l’espace d’adressage de la mémoire hôte.
L’ordre dans lequel les images sont reçues sur une file d’attente de réception VMQ doit être conservée lorsque les images de cette file d’attente sont indiquées dans la pile des pilotes.
La carte réseau doit allouer suffisamment d’espace mémoire de remplissage dans chaque mémoire tampon post-lookahead. Cette allocation permet aux données de lookahead d’être copiées dans la partie de remplissage de la mémoire tampon post-lookahead, et permet à la trame d’être remise à la machine virtuelle dans une mémoire tampon contiguë.
S’il n’existe aucun mécanisme dans le matériel pour répondre à ces exigences pour la mémoire partagée VMQ, le matériel qui prend en charge la collecte de points DMA côté réception peut obtenir les mêmes résultats en allouant deux mémoires tampons de réception pour chaque trame reçue. Dans ce cas, la taille de la première mémoire tampon est limitée à la taille de lookahead demandée.
Si la carte réseau ne peut pas répondre à ces exigences pour la mémoire partagée VMQ par n’importe quelle méthode, le VSP alloue de la mémoire pour les mémoires tampons de réception vmQ à partir de l’espace d’adressage de l’hôte et copie les paquets reçus de la carte réseau vers l’espace d’adressage de la machine virtuelle.
Comment Windows Server 2012 et versions ultérieures résolvent le problème de sécurité
À compter de Windows Server 2012, le VSP n’alloue pas de mémoire partagée de la machine virtuelle pour les mémoires tampons de réception VMQ. Au lieu de cela, le VSP alloue de la mémoire pour les mémoires tampons de réception VMQ à partir de l'espace d'adressage de l'hôte, puis copie les paquets reçus des mémoires tampons de réception de la carte réseau vers l'espace d'adressage de la machine virtuelle.
Les points suivants s’appliquent aux pilotes miniport VMQ qui s’exécutent sur Windows Server 2012 et versions ultérieures de Windows :
Pour les pilotes miniport NDIS 6.20 VMQ, aucune modification n’est requise. Toutefois, lorsque le VSP alloue une file d’attente de machine virtuelle en émettant une requête de méthode OID (identificateur d’objet) de OID_RECEIVE_FILTER_ALLOCATE_QUEUE, il définit le membre LookaheadSize de la structure NDIS_RECEIVE_QUEUE_PARAMETERS sur zéro. Cela force un pilote miniport à ne pas fractionner le paquet en mémoires tampons pré-lookahead et post-lookahead.
À compter de NDIS 6.30, les pilotes miniport VMQ ne doivent pas publier la prise en charge du fractionnement des données de paquets en mémoires tampons de pré-lookahead et post-lookahead. Lorsqu’un pilote miniport enregistre ses capacités VMQ, il doit suivre les règles suivantes lorsqu’il initialise la structure NDIS_RECEIVE_FILTER_CAPABILITIES :
Le pilote miniport ne doit pas définir l’indicateur NDIS_RECEIVE_FILTER_LOOKAHEAD_SPLIT_SUPPORTED dans le membre Flags.
Le pilote miniport doit définir les membres MinLookaheadSplitSize et MaxLookaheadSplitSize sur zéro.
Pour plus d’informations sur l’inscription des fonctionnalités VMQ, consultez Détermination des fonctionnalités VMQ d’une carte réseau.