Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema werden die potenziellen Sicherheitsprobleme erläutert, die mit dem Zuordnen des gemeinsam genutzten Speichers von einem virtuellen Computer (VM) für VMQ-Empfangspuffer verbunden sind. Das Thema enthält die folgenden Abschnitte:
Übersicht über die Sicherheitsprobleme mit freigegebenem VM-Speicher
So beheben Windows Server 2012 und höhere Versionen das Sicherheitsproblem
Anmerkung In Hyper-V wird eine untergeordnete Partition auch als VM bezeichnet.
Übersicht über die Sicherheitsprobleme mit freigegebenem VM-Speicher
VMs sind keine vertrauenswürdigen Softwareentitäten. Das heißt, ein bösartiger virtueller Computer darf nicht in der Lage sein, andere VMs oder das Verwaltungsbetriebssystem zu beeinträchtigen, das in der übergeordneten Hyper-V Partition ausgeführt wird. Dieser Abschnitt enthält Hintergrundinformationen und Anforderungen, um sicherzustellen, dass Treiberautoren VMQ-Sicherheitsprobleme und Anforderungen für gemeinsam genutzten Speicher verstehen. Weitere Informationen zu gemeinsam genutztem Speicher finden Sie im Abschnitt zum Schreiben von VMQ-Treibern im Thema "Ressourcenzuweisung für gemeinsam genutzte Speicher".
In der virtualisierten Umgebung kann der gemeinsam genutzte virtuelle Computerspeicher vom virtuellen Computer angezeigt oder geändert werden. Das Anzeigen oder Ändern von Daten, die anderen virtuellen Computern zugeordnet sind, ist jedoch nicht zulässig. VMs dürfen auch nicht auf den Verwaltungsbetriebsadressraum zugreifen.
Der Kopfzeilenteil der empfangenen Pakete muss geschützt sein. Eine VM darf das Verhalten des Hyper-V erweiterbaren Switchs in einem virtuellen Netzwerkdienstanbieter (Virtual Service Provider, VSP) nicht beeinflussen. Daher muss die VLAN-Filterung (virtuelles LAN) erfolgen, bevor der Netzwerkadapter DMA verwendet, um die Daten in den gemeinsam genutzten VM-Speicher zu übertragen. Außerdem darf das Lernen der MAC-Adressen des Schalters durch die Medienzugriffskontrolle (MAC) nicht beeinträchtigt werden.
Wenn der Hyper-V erweiterbaren Switchport, der mit einer VM verbunden ist, über einen zugeordneten VLAN-Bezeichner verfügt, muss der Hostcomputer sicherstellen, dass die Ziel-MAC-Adresse und der VLAN-Bezeichner des eingehenden Frames mit den entsprechenden Attributen des Ports übereinstimmen, bevor der Host das Paket an den virtuellen Netzwerkadapter des virtuellen Computers weiterleitet. Wenn der VLAN-Bezeichner des Frames nicht mit dem VLAN-Bezeichner des Ports übereinstimmt, wird das Paket gelöscht. Wenn die Empfangspuffer für einen virtuellen Netzwerkadapter vom Hostspeicher zugewiesen werden, kann der Host den VLAN-Bezeichner überprüfen und den Frame bei Bedarf ablegen, bevor der Inhalt des Frames für die Ziel-VM sichtbar wird. Wenn der Frame nicht in den Adressraum eines virtuellen Computers kopiert wird, kann auf diesen virtuellen Computer nicht zugegriffen werden.
Wenn VMQ jedoch so konfiguriert ist, dass es den freigegebenen Speicher verwendet, nutzt der Netzwerkadapter DMA, um eingehende Frames direkt in den VM-Adressraum zu übertragen. Diese Übertragung führt zu einem Sicherheitsproblem, bei dem ein virtueller Computer den Inhalt der empfangenen Frames untersuchen kann, ohne auf den erweiterbaren Switch zu warten, um die erforderliche VLAN-Filterung anzuwenden.
So behebt Windows Server 2008 R2 das Sicherheitsproblem
Bevor der VSP in Windows Server 2008 R2 eine VM-Warteschlange konfiguriert, um gemeinsam genutzten Speicher zu verwenden, der aus dem Adressraum des virtuellen Computers zugewiesen ist, verwendet er den folgenden Filtertest für die Warteschlange.
(MAC address == x) && (VLAN identifier == n)
Wenn die Netzwerkadapterhardware diesen Test vor der DMA-Übertragung an die Empfangspuffer unterstützen kann, kann der Netzwerkadapter Entweder Frames mit ungültigen VLAN-Bezeichnern ablegen oder an die Standardwarteschlange senden, sodass sie vom erweiterbaren Switch herausgefiltert werden können. Wenn der Miniporttreiber in einer Anforderung zum Festlegen eines Filters mit diesem Test in einer Warteschlange erfolgreich ist, kann der erweiterbare Switch den freigegebenen VM-Speicher für diese Warteschlange verwenden. Wenn die Netzwerkadapterhardware jedoch nicht in der Lage ist, die Frames basierend auf der Ziel-MAC-Adresse und dem VLAN-Bezeichner zu filtern, verwendet der erweiterbare Switch den gemeinsam genutzten Hostspeicher für diese Warteschlange.
Der erweiterbare Switch überprüft die Quell-MAC-Adresse der empfangenen Frames, um die Routinginformationen für übertragungsframes zu konfigurieren, d. h. es ähnelt einem physischen Lernschalter. Es ist möglich, Firewallfiltertreiber im Hoststapel zu installieren. Beispiel: oberhalb des Miniporttreibers für die Netzwerkadapterhardware und unterhalb des erweiterbaren Switchtreibers. Firewall-Filtertreiber können vor dem erweiterbaren Switch auf Daten in einem empfangenen Frame zugreifen. Wenn der gesamte Empfangspuffer für jeden Frame aus dem virtuellen Adressraum zugewiesen wird, könnte eine schädliche VM auf Teile des Frames zugreifen, die entweder von einem Filtertreiber oder dem erweiterbaren Switch untersucht werden, der auf dem Host läuft.
Um dieses Sicherheitsproblem zu beheben, muss der Netzwerkadapter bei Verwendung des freigegebenen VM-Speichers für eine VM-Warteschlange das Paket auf einen Byte-Offset teilen, der mindestens die Lookahead-Größe aufweist, bei der es sich um einen vordefinierten festen Wert handelt. Alle Lookahead-Daten – also Daten, die jenseits des Byte-Offsets für die Lookahead-Größe liegen – müssen mittels DMA in den gemeinsam genutzten Speicher übertragen werden, der dafür zugewiesen wurde. Die Daten nach dem Lookahead – der Rest der Framenutzlast – sollten mit DMA an freigegebenen Speicher übertragen werden, der für die Daten nach dem Lookahead zugewiesen wurde.
Die folgende Abbildung zeigt die Beziehungen der Netzwerkdatenstrukturen, wenn die eingehenden Daten in Lookahead- und Post-Lookahead-Speicherpuffer aufgeteilt werden.
Die Zusammenfassungsanforderungen für gemeinsam genutzten VMQ-Speicher sind wie folgt:
Ein Netzwerkadapter kann einen empfangenen Frame an einer Netzwerkheadergrenze teilen, die größer als die Lookahead-Größe ist. Wenn von NDIS angefordert, müssen jedoch ohne Ausnahme alle Frames, die einem VMQ zugewiesen und empfangen wurden, an oder über der von NDIS geforderten Grenze der Lookahead-Größe aufgeteilt werden.
Die Lookahead-Daten müssen mit DMA an gemeinsam genutzten Speicher übertragen werden, der vom Miniporttreiber zugewiesen wird. Der Miniporttreiber muss im Zuordnungsaufruf angeben, dass der Speicher für Lookahead-Daten verwendet wird.
Die Daten nach dem Lookahead müssen mit DMA an gemeinsam genutzten Speicher übertragen werden, der vom Miniporttreiber zugewiesen wird. Der Miniporttreiber muss im Zuordnungsaufruf angeben, dass der Speicher für Nachschlagekopfdaten verwendet wird.
Miniporttreiber dürfen nicht davon abhängig sein, welchen Adressraum NDIS verwendet, um die Anforderung der freigegebenen Speicherzuweisung abzuschließen. Das heißt, der gemeinsam genutzte Speicheradressraum für Lookahead- oder Daten nach dem Lookahead ist implementierungsspezifisch. In vielen Fällen kann NDIS oder der erweiterbare Switch möglicherweise alle Anforderungen, einschließlich derjenigen für die Verwendung nach der Lookahead-Phase, aus dem Hostspeicheradressraum erfüllen.
Die Reihenfolge, in der Frames in einer VMQ-Empfangswarteschlange empfangen werden, muss beibehalten werden, wenn die Frames in dieser Warteschlange entlang der Treiberkette weitergeleitet werden.
Der Netzwerkadapter muss in jedem Post-Lookahead-Puffer genügend Speicherplatz zuweisen. Mit dieser Zuordnung können die Lookahead-Daten in den Backfill-Teil des Post-Lookahead-Puffers kopiert werden, und der Frame kann in einem zusammenhängenden Puffer an die virtuelle Maschine übermittelt werden.
Wenn es keinen Mechanismus in der Hardware gibt, um diese Anforderungen für den gemeinsam genutzten VMQ-Speicher zu erfüllen, kann die Hardware, die scatter-gather DMA auf der Empfangsseite unterstützt, dieselben Ergebnisse erzielen, indem zwei Empfangspuffer für jeden empfangenen Frame zugewiesen werden. In diesem Fall ist die Größe des ersten Puffers auf die angeforderte Lookahead-Größe beschränkt.
Wenn der Netzwerkadapter diese Anforderungen für den gemeinsam genutzten VMQ-Speicher durch irgendeine Methode nicht erfüllen kann, weist der VSP Speicher für die VMQ-Empfangspuffer vom Hostadressraum zu und kopiert die empfangenen Pakete aus den Netzwerkadapter-Empfangspuffern in den virtuellen Adressraum.
So beheben Windows Server 2012 und höhere Versionen das Sicherheitsproblem
Ab Windows Server 2012 weist der VSP keinen gemeinsam genutzten Speicher vom virtuellen Computer für die VMQ-Empfangspuffer mehr zu. Stattdessen weist der VSP Speicher für die VMQ-Empfangspuffer aus dem Hostadressraum zu und kopiert dann die empfangenen Pakete aus den Empfangspuffern des Netzwerkadapters in den VM-Adressraum.
Die folgenden Punkte gelten für VMQ-Miniporttreiber, die unter Windows Server 2012 und höheren Versionen von Windows ausgeführt werden:
Für NDIS 6.20 VMQ-Miniporttreiber ist keine Änderung erforderlich. Wenn der VSP jedoch eine VM-Warteschlange zuweist, indem eine OID-Methode-Anfrage (Objektbezeichner) von OID_RECEIVE_FILTER_ALLOCATE_QUEUE angefordert wird, wird das LookaheadSize-Mitglied der NDIS_RECEIVE_QUEUE_PARAMETERS-Struktur auf Null festgelegt. Dies wird den Miniport-Treiber dazu zwingen, das Paket nicht in Vorab-Lookahead- und Nach-Lookahead-Puffer zu unterteilen.
Ab NDIS 6.30 sollten VMQ-Miniporttreiber keine Unterstützung für das Aufteilen von Paketdaten in Vorab-Lookahead- und Nach-Lookahead-Puffer bereitstellen. Wenn ein Miniporttreiber seine VMQ-Funktionen registriert, muss er die folgenden Regeln befolgen, wenn er die NDIS_RECEIVE_FILTER_CAPABILITIES Struktur initialisiert:
Der Miniporttreiber darf das NDIS_RECEIVE_FILTER_LOOKAHEAD_SPLIT_SUPPORTED Flag nicht im Flags-Element festlegen.
Der Miniporttreiber muss die Elemente "MinLookaheadSplitSize " und "MaxLookaheadSplitSize " auf Null festlegen.
Weitere Informationen zum Registrieren von VMQ-Funktionen finden Sie unter Ermitteln der VMQ-Funktionen eines Netzwerkadapters.