Zusammenfassung

  • RFC 7145 untersagt der iSER-Schicht des Initiators, sich bei der lokalen STag-Invalidierung auf den Peer zu verlassen: Send with Invalidate ist optional; wenn die Ungültigkeit erwartet wird, muss die lokale Schicht prüfen und einen noch gültigen Tag selbst invalidieren.
  • Es geht um die Lebensdauer einer Ressource: Ein weiterhin gültiger STag kann den I/O-Puffer über RDMA auch nach dem Auftrag erreichbar halten, für den er angekündigt wurde.

Der Auftrag ist beendet. Der Zugriff vielleicht nicht.

Das Ende eines Speicherbefehls ist sichtbar: Eine Antwort trifft ein, der Auftrag wird abgeschlossen, und die Software möchte den Puffer womöglich wiederverwenden. Bei RDMA bleibt eine weniger sichtbare Frage offen: Ist die Fähigkeit der Gegenseite, auf diesen Speicher zuzugreifen, tatsächlich entzogen? In iSER bezeichnet der Steering Tag (STag) einen I/O-Puffer, den ein Knoten für den direkten Lese- oder Schreibzugriff des anderen über RDMA ankündigt. Der Tag enthält nicht die Daten; er gehört zum Zugriffspfad auf den Speicherbereich.

RFC 7145 löste 2014 RFC 5046 ab und bestimmt, wer die abschließende Prüfung verantwortet. Wenn das zugrunde liegende RDMA-fähige Protokoll es unterstützt, kann die Zielseite mit Send with Invalidate beim Senden der SCSI-Antwort den Tag automatisch invalidieren. Diese Nachrichtenart ist jedoch optional. Der Initiator darf also nicht voraussetzen, dass der Peer sie verwendet hat. Soll ein STag nach Abschluss ungültig sein, muss die lokale iSER-Schicht seinen Zustand prüfen und ihn invalidieren, falls er noch gültig ist. RFC 7145

Eine empfangene Antwort und ein veränderter lokaler Speicherregistrierungszustand sind zwei verschiedene Tatsachen. Für den normalen Abschluss empfiehlt die Norm, den angekündigten STag zu invalidieren. Bei bidirektionalen Befehlen und abnormalem Abschluss ist die automatische Invalidierung nicht immer der ganze Weg. Außerdem kann eine Send-with-Invalidate-Nachricht nur einen Tag benennen; bei bestimmten bidirektionalen Transfers muss der Initiator den anderen ausdrücklich invalidieren.

Endet ein Auftrag ohne Antwort-PDU, sieht RFC 7145 einen gesonderten Pfad vor: Ressourcen freigeben, zugehörige Tags und das lokale Mapping auffinden und invalidieren.

Der Grund ist die Dauer der Exposition. Bleibt ein STag etwa zum Zwischenspeichern und Wiederverwenden gültig, bleibt auch der I/O-Puffer über das RDMA-Protokoll nach dem ursprünglichen iSCSI-Vorgang aus dem Netz erreichbar. Das ist kein Beleg für Missbrauch. Es verlängert aber das Zeitfenster, in dem der Speicher erreichbar ist. Der Abschluss des Befehls allein weist nicht nach, dass dieses Fenster geschlossen wurde.

Optimierungen bleiben möglich: Unterstützt das RDMA-Protokoll die automatische Invalidierung, kann sie genutzt werden. Eine optionale Aktion der Gegenseite darf jedoch nicht der einzige Nachweis für einen lokalen Zustandswechsel sein. RFC 7145 berichtet weder über einen konkreten Angriff noch über einen Herstellerfehler oder eine Quote nichtkonformer Implementierungen. Die Invalidierung ersetzt auch nicht die Authentifizierung und die übrigen Sicherheitsanforderungen von iSCSI und RDMA. Die Änderungshistorie zu RFC 5046 hält fest, dass RFC 7145 aus Sicherheitsgründen die Verantwortung des Initiators für die lokale Invalidierung klarstellte. RFC 5046 · RFC 7143 Quellen: Informationsseite des RFC Editors.