摘要

  • RFC 7145 明确规定，iSER 发起端不能指望对端替本地 STag 失效：Send with Invalidate 是可选机制；若任务结束后应当失效，本地层必须检查，并在标签仍有效时自行使其失效。
  • 这不仅是消息格式问题，也关乎资源生命周期：仍有效的 STag 可能让 I/O 缓冲区在原任务结束后继续通过 RDMA 被访问。

命令完成，不等于权限已经收回

存储命令的完成通常很清楚：响应到达，任务收尾，软件准备复用缓冲区。RDMA 路径还有一个不那么显眼的问题：远端访问这块内存的能力是否真的撤销了？在 iSER 中，Steering Tag（STag）标识一个 I/O 缓冲区；发起端把它公布给对端，对端便可通过 RDMA 读写相应区域。标签本身不是数据，却参与了数据区域的寻址与访问。

RFC 7145 于 2014 年发布，取代 RFC 5046，并明确谁负责最后核验。如果底层 RDMA 协议支持，目标端可以在携带 SCSI 响应的 Send with Invalidate 消息中自动使标签失效。但该消息机制不是必选项，因此发起端不能把对端是否使用它当成前提。任务结束后若预期 STag 已失效，发起端的 iSER 层必须查看其状态；仍有效就必须自行失效。RFC 7145

这里的关键是：收到响应，与本地内存注册状态已改变，是两件不同的事。对正常完成的任务，标准建议失效已公布的 STag；双向命令或异常结束会使自动失效路径更复杂。一个 Send with Invalidate 消息也只能携带一个待失效标签，所以双向传输时，另一个标签可能仍须由发起端显式处理。若命令结束时没有发送响应 PDU，RFC 7145 另设任务资源释放流程：找到该任务关联的标签和本地映射，再将其失效。

原因在于暴露时间。如果为了缓存、复用而保留 STag，相应缓冲区就仍可能经 RDMA 协议被网络访问，时间超出最初的 iSCSI 操作。保留标签不等于已经发生滥用；它只是延长了资源可被触达的窗口。因此，命令完成本身不能证明窗口已经关闭。

这套设计没有禁止性能优化。底层协议支持时，自动失效仍可使用；但一项可选的远端动作不能成为本地状态变更的唯一凭据。RFC 7145 没有记录特定攻击、厂商缺陷或实现不合规的发生率；失效机制也不替代 iSCSI 或 RDMA 的认证和其他安全要求。RFC 5046 的变更说明指出，RFC 7145 出于安全原因澄清了发起端承担本地失效责任。RFC 5046 · RFC 7143 来源：RFC 编辑器信息页。