Résumé

  • RFC 7145 interdit à la couche iSER initiatrice de compter sur le pair pour invalider un STag local : Send with Invalidate est facultatif et la couche locale doit vérifier puis invalider le tag lorsque c’est attendu.
  • L’enjeu est la durée de vie d’une ressource : un STag encore valide peut laisser le tampon accessible par RDMA après la tâche qui l’avait annoncé.

La tâche est finie, pas forcément l’accès

La fin d’une commande de stockage est visible : une réponse arrive, la tâche se clôt et le logiciel peut vouloir réutiliser son tampon. Avec RDMA, une question demeure en arrière-plan : la capacité d’accès distant à cette mémoire a-t-elle vraiment été retirée ? Dans iSER, le Steering Tag (STag) identifie un tampon d’E/S annoncé pour permettre à l’autre nœud de lire ou d’écrire directement par RDMA. Ce n’est pas le contenu du tampon, mais l’identifiant qui participe à son adressage.

Publié en 2014 pour remplacer RFC 5046, RFC 7145 précise à qui revient le dernier contrôle. Send with Invalidate peut invalider automatiquement un tag lorsqu’il accompagne la réponse de la cible, si la couche RDMA le prend en charge. Mais son emploi est facultatif. L’initiateur ne peut donc pas supposer que le pair l’a utilisé. Si l’achèvement d’une tâche implique que le STag soit invalide, iSER doit vérifier son état et l’invalider encore valide. RFC 7145

La réponse et l’état local de l’enregistrement mémoire sont deux faits distincts. En fin normale, la recommandation est d’invalider le STag annoncé ; une commande bidirectionnelle ou un achèvement anormal peut empêcher l’invalidation automatique attendue. De plus, un message Send with Invalidate ne peut désigner qu’un seul tag : dans certains transferts bidirectionnels, l’initiateur doit donc invalider explicitement l’autre. Si la commande prend fin sans PDU de réponse, le standard prévoit une voie différente de libération des ressources, qui retrouve les tags associés et les invalide.

La raison est concrète. Si l’on conserve un STag — par exemple pour le réutiliser plus tard — le tampon reste exposé au réseau par la couche RDMA au-delà de l’opération iSCSI d’origine. Cette conservation n’est pas la preuve d’un abus ; elle prolonge simplement la période pendant laquelle la ressource est accessible. Une commande achevée ne démontre donc pas, à elle seule, que la fenêtre d’accès est fermée.

RFC 7145 autorise toujours les optimisations : l’invalidation automatique peut être utilisée lorsque le protocole RDMA sous-jacent la prend en charge. Mais une action distante facultative ne peut constituer l’unique preuve d’une transition d’état local. Le texte ne rapporte ni incident, ni défaut d’implémentation précis, ni fréquence de non-conformité. Il distingue aussi l’invalidation des autres protections : l’authentification et les exigences de sécurité iSCSI/RDMA restent nécessaires. L’historique de RFC 5046 indique que RFC 7145 a clarifié, pour des raisons de sécurité, que l’initiateur est responsable de l’invalidation locale. RFC 5046 · RFC 7143 Sources : Page d’information du RFC Editor.