NVMe 2.0a - Sanitize

目录

8.21 Sanitize Operations

8.21.1

---

NVMe 2.0对sanitize的改动有四点：

1. Sanitize Status log page更新要在NVM subsystem中controller ready前初始化

2. sanitize限制操作不再包含Flush.

3. 如果最近的Sanitize操作成功，或者当前没有正在进行的sanitize操作，那么做sanitize Action = 001b(Exit Failure Mode)不能失败

4. sanitize in progress 允许的Admin Command新增NVMe Fabric Command: Disconnect, 参考2.0a图139

下面是个人对sanitize这节的理解，仅供参考，欢迎评论区指正交流。

8.21 Sanitize Operations

Sanitize操作会更改 NVM Subsystem中的所有user data，从而无法从任何cache、非易失性介质或任何Controller Memory Buffer中恢复先前的user data。 Controller Memory Buffer中的Submission Queues和Completion Queues是否被Sanitize操作改变是特定实现的； 存储在所有Controller Memory Buffer中的所有其他数据都被Sanitize操作更改。 如果user data的一部分未被更改并且Sanitize操作成功完成，则 NVM Subsystem应确保该部分user data永久不可访问以供 NVM Subsystem内的任何未来使用（例如，从 NVM media、caches、 或任何Controller Memory Buffer）,并且这部分user data永久无法通过任何接口访问 NVM Subsystem，包括 NVMe-MI。

sanitize操作的范围是 NVM Subsystem中能够包含user data的所有位置，包括caches、Persistent Memory Regions以及unallocated或deallocated的介质区域。如果 NVM Subsystem的组成（参见NVMe 2.0a base第 3.2.4 节）发生变化（例如，添加了新domain，或发生了division event）并且该变化阻止了sanitize操作的成功完成，则sanitize操作将失败。sanitize操作不会影响Replay Protected Memory Block、boot partitions或其他不包含user data的media和caches。sanitize操作还可以根据需要更改log page（如，防止从log page information中导出user data）。只有在 NVM Subsystem未被划分时才能开始sanitize操作（请参阅NVMe 2.0a base第 3.2.4 节）。一旦开始，sanitize操作将无法中止并在CLR后继续，包括power cycle。有关sanitize操作的更多信息，请参阅NVMe 2.0a base附录 A。

Sanitize 命令（请参阅NVMe 2.0a base第 5.24 节）用于启动sanitize操作或从先前失败的sanitize操作中恢复。 所有sanitize操作都在后台执行（即sanitize命令的完成并不表示sanitize操作的完成）。 sanitize操作的完成在Sanitize Statu日志页中(LID:81h)指示，并且带有Sanitize Operation Completed异步事件或Sanitize Operation Completed With Unexpected Deallocation异步事件（如果Asynchronous Event Request Command未完成）。

Identify Controller data structure的Sanitize Capabilities (SANICAP) 字段（参见NVMe 2.0a base图 275）表示支持的sanitize操作类型和特定sanitize操作的控制器属性。

sanitize操作类型有：

1. Block Erase sanitize操作使用low-level block erase方法更改user data，该方法只对media有效，用于 NVM subsystem中可能存储 user data的media上的所有位置；
2. Crypto Erase sanitize 操作通过更改 NVM subsystem中可能存储user data的media上所有位置的media加密密钥来更改用户数据；
3. Overwrite sanitize 操作通过将固定的数据pattern或相关数据pattern写入 NVM subsystem内media上的所有位置来更改user data，其中user data可能存储一次或多次。 图 474 定义了写入的数据pattern。

Identify controller针对sanitize操作的属性包括：

1. No-Deallocate Modifying Media After Sanitize (NODMMAS)： 指示在sanitize操作成功完成后控制器是否修改了介质，该操作在Sanitize命令中将No-Deallocate After Sanitize置为“1” ；
2. No-Deallocate Inhibited (NDI) ：指示控制器是否支持sanitize命令中的No-Deallocate After Sanitize位。

NODMMAS 字段（参见NVMe 2.0a base图 275）指定，如果sanitize命令包括No-Deallocate After Sanitize设置为“1”并且 NODMMAS 设置为 10b，则sanitize操作具有关联的额外media修改操作。这个额外的media修改操作对请求的sanitize操作的结果起作用，目的是使所有 LBA 内容都可读。有关sanitize操作和与完整性电路交互的更多信息，请参阅NVMe 2.0a base附录 A.3。

此额外的media修改应在 NVM subsystem下列操作之前完成：

a) 通过Asynchronous Event报告sanitize完成（参见NVMe 2.0a base第 5.2 节）；和

b) 在Sanitize Status log中报告sanitize完成（参见第 5.16.1.25 节）。

Overwrite Sanitize 操作是特定于media的，可能不适用于所有media类型。例如，如果介质是 NAND，则多次覆盖操作可能会对介质耐久性产生不利影响。

Figure 474: Sanitize Operations – Overwrite Mechanism

OIPBP	Overwrite Pass Count	Overwrite Pass Number	User Data except PI Metadata	Protection Information​​​​​​​
0	All	All	Overwrite Pattern	Each byte set to FFh
1	Even	First	Inversion of Overwrite Pattern	Each byte cleared to 00h
		Subsequent	Inversion of Overwrite Pattern1 from previous pass (i.e., each bit XORed with ‘1’)
1	Odd	First	Overwrite Pattern	Each byte set to FFh
		Subsequent	Inversion of Overwrite Pattern1 from previous pass (i.e., each bit XORed with ‘1’)
1. 参数在开始Overwrite操作的相应sanitize命令的CDW 10 和CDW 11 中指定。Overwrite Invert Pattern Between Passes (OIPBP) 字段在CDW 10 中定义。Overwrite Pass Count在CDW 10 中定义。覆盖模式在CDW 11 中定义。请参阅NVMe 2.0a base第 5.24 节。 2. 如果元数据中存在保护信息。

要开始sanitize操作，主机提交sanitize命令，指定sanitize操作类型之一（即Block Erase, Overwrite, 或Crypto Erase）。主机设置命令参数，包括 Allow Unrestricted Sanitize Exit 位和 No-Deallocate After Sanitize 位。验证sanitize命令参数后，控制器在后台开始sanitize操作，更新Sanitize Status log page，然后以成功完成状态完成sanitize命令。如果sanitize操作之后是相关的额外介质修改操作（参见NVMe 2.0a base图 275 中的 NODMMAS），则相关的额外介质修改操作应在控制器报告sanitize操作完成之前完成。如果sanitize命令以成功完成以外的任何状态代码完成，则控制器不应开始sanitize操作并且不应更新Sanitize Status log page。控制器忽略 SMART/ Health Information log page中的Critical Warning（例如，只读模式）并尝试完成请求的sanitize操作。有关在处理 Format NVM 命令期间对Admin command限制的更多信息，请参阅NVMe 2.0a base第 5 节。
在成功完成sanitize操作之后，在 I/O Command Set规范中定义了由 NVM subsystem的审计（audit, 参见NVMe 2.0a base第 1.5.6 节）产生的user data、PI和non-PI 元数据的值。

Sanitize Status log page（请参阅NVMe 2.0a base第 5.16.1.25 节）包含sanitize操作的估计时间和有关最近开始的sanitize操作的一致信息快照，包括sanitize操作是否正在进行、sanitize操作参数和最近的sanitize操作状态。 如果sanitize操作正在进行中或相关的额外介质修改操作正在进行中，控制器应报告sanitize操作正在进行中。 如果sanitize操作未在进行中，则log page中的Global Data Erased位指示 NVM subsystem是否可能包含user data（即，自最近一次成功的sanitize操作以来尚未写入）。

Sanitize Status log page应更新如下：

• 在 NVM 子系统中的任何控制器准备就绪之前进行初始化，如NVMe 2.0a base第 3.5.3 和 3.5.4 节所述；
• 在启动sanitize操作的sanitize命令完成之前更新（即，在为sanitize命令发布completion queue entry前）；且
• 在sanitize操作完成时更新（例如，紧接在为Sanitize Operation Completed异步事件或Sanitize Operation Completed With Unexpected Deallocation异步事件完成而发布完成队列条目之前）。

Sanitize status log page在sanitize操作期间定期更新，使主机可以使用处理信息。

在sanitize操作期间，主机可能会定期检查sanitize Status log page以检查进度，但是，主机应限制此轮询（例如，最多每几分钟一次）以避免干扰sanitize操作本身的进度.

完成sanitize操作后：

• 如果sanitize操作成功，则Global Data Erased 位应设置为“1”；
• 更新Sanitize Status log page；
• 提交sanitize命令的控制器使用以下信息完成Asynchronous Event Request命令（如果有一个未完成）：
  1. Log Page Identifier字段设置为 81h（即sanitize status）；
  2. Asynchronous Event Information 字段设置为 Sanitize Operation Completed 或 Sanitize Operation Completed With Unexpected Deallocation 异步事件（参见第 5.2 节）；且
  3. Asynchronous Event Type字段设置为 110b（即 I/O Command specific状态）；且
  • NVM subsystem中的所有控制器都可以恢复因sanitize操作开始时暂停的power management。

sanitize操作完成后，主机应读取sanitize status log page，并将Retain Asynchronous Event位清除为“0”（如果生成了异步事件，则清除异步事件）。

如果sanitize操作失败，NVM subsystem中的所有控制器应中止sanitize操作期间不允许的任何命令，状态代码为Sanitize Failed（请参阅NVMe 2.0a base第 8.21.1 节），直到开始后续sanitize操作或从失败中成功恢复进行sanitize操作。后续成功的sanitize操作或Exit Failure Mode操作可用于从失败的sanitize操作中恢复。有关恢复的详细信息，请参阅NVMe 2.0a base第 5.24 节。

如果支持 Sanitize 命令，则 NVM subsystem和所有控制器应：

• 支持sanitize status log page；
• 支持Sanitize Operation Completed 异步事件；
• 如果支持Sanitize Config功能，则支持Sanitize Operation Completed With Unexpected Deallocation异步事件；
• 支持sanitize命令的Exit Failure Mode操作；
• 至少支持以下一个sanitize操作类型：Block Erase、Overwrite或Crypto Erase；
• 支持同一套sanitize操作类型；且
• 在Identify Controller data structure的Sanitize Capabilities字段中指明支持的sanitize操作类型。

Sanitize Config Feature Identifier（请参阅NVMe 2.0a base第 5.27.1.19 节）包含 No-Deallocate Response Mode (NODRM) 位，该位指定控制器对使用 No-Deallocate After Sanitize 位处理的 Sanitize 命令的响应（请参阅NVMe 2.0a base图 303），如果在Identify Controller data structure的Sanitize Capabilities字段中将No-Deallocate Inhibited位设置为“1”，则No-Deallocate After Sanitize置为“1”（参见NVMe 2.0a base图 275）。在 No-Deallocate Error Response Mode下，控制器中止此类 Sanitize 命令，状态代码为 Invalid Field in Command。在 No-Deallocate Warning Response Mode 下，控制器处理此类sanitize命令，如果结果sanitize操作成功完成，则在Sanitize Status log page 的Sanitize Status字段bit 2:0中设为 100b（参见NVMe 2.0a base图267）。

8.21.1

在执行sanitize操作过程和sanitize操作已经失败但尚未从该故障中成功恢复时，NVM subsystem中所有enable的控制器和namespace都被限制为仅执行一组有限的操作。

在进行sanitize操作时：

1. NVM  subsystem中的所有控制器应仅处理NVMe 2.0a base图 139 中列出的Admin Command，但须遵守该图中规定的附加限制；
2. 除 Flush 命令外的所有 I/O 命令都应中止，状态代码为 Sanitize In Progress；
3. 7.1 节规定了Flush 命令的处理；
4. 如果 NVM  subsystem中的任何控制器获取到NVMe 2.0a base图 139 中未明确允许的任何命令或命令选项，则应中止并显示 Sanitize In Progress 状态代码；且
5. 应防止enable Persistent Memory Region（即，将PMRCTL.EN 设置为“1”不会导致PMRSTS.NRDY被清为“0”）。

当发生了失败的sanitize操作，但后续的sanitize操作尚未开始，并且尚未从失败的sanitize操作中成功恢复：

1. NVM  subsystem中的所有控制器应仅处理图 139 中列出的 Sanitize 命令（参见NVMe 2.0a base第 5.24 节）和 Admin 命令，但须遵守该图中指出的附加限制；
2. 除 Flush 命令（参见NVMe 2.0a base第 7.1 节）之外的所有 I/O 命令都应中止，状态代码为 Sanitize Failed；
3. Sanitize 命令允许有操作限制（参见NVMe 2.0a base第 5.24 节）；
4. 除了Sanitize 命令之外，如果NVM  subsystem中的任何控制器获取到图139 中未明确允许的任何其他命令或命令选项，则应中止并显示Sanitize Failed 状态代码；并且
5. 应防止enable Persistent Memory Region（即，将 PMRCTL.EN 设置为“1”不会导致 PMRSTS.NRDY 被清为“0”）。