Sanitize简介

Sanitize命令用于启动Sanitize操作或从以前失败的Sanitize操作中恢复。可能支持的Sanitize类型是块擦除、加密擦除和覆盖(overwrite)。所有Sanitize操作都在后台处理(即,Sanitize命令的完成并不表示Sanitize操作的完成)。有关Sanitize操作的详细信息,请参阅8.15节。

三种Sanitize方式

  1.  Block Erase(就是块擦除指令,擦除后的值不同介质是不同的);
    
  2.  Crypto Erase(即如果用户数据是加密的,则只擦除秘钥,这样也能达到清除数据的目的);
    
  3.  Overwrite(覆盖写操作,此操作是在写入指定的值覆盖之前的数据,对于nand来说,这样会影响寿命,所以一般不采用此操作)
    

当Sanitize操作在任何controller上启动时,NVM子系统中的所有controller有如下约束:

  1.  1.应该清除任何Sanitize Operation Completed asynchronous event或sanitize操作以Unexpected Deallocation asynchronous event完成;
     2.更新sanitize状态日志;
     3.在进行中的sanitize操作中,应中止任何不允许的命令(已提交的或正在进行的);
     4.终止正在进行的设备自检操作;
     5.暂停第8.4.2节所述的自主电源状态管理活动;
     6.应释放任何开放流的流标识符。
    

如果一个sanitize操作没有在进行中,并且最近的sanitize操作没有失败,那么一个sanitize操作设置为001b(即,退出失败模式)的sanitize命令将以成功完成的状态完成,并且不执行其他操作。

当sanitize操作正在进行时,NVM子系统中的所有控制器应中止在sanitize操作期间不允许的任何命令,其状态为正在进行中的sanitize,并且持久性内存区域(Persistent Memory Region)不会被使能。
如果sanitize操作失败了,上述内容仍然是如此,直到后续有新的sanitize操作开启或者从失败的sanitize操作中成功恢复。

如果最近的失败的sanitize操作是在无限制完成模式下启动的(即。在Sanitize命令中将AUSE位设置为’1’)。故障恢复要求主机以受限或不受限完成模式发出后续Sanitize命令,或者以退出失败模式操作发出后续Sanitize命令。

如果最近一次失败的sanitize操作是以受限完成模式启动的(即,在sanitize命令中,AUSE位被清除为’0’),则失败恢复要求主机在受限完成模式下发出后续的sanitize命令。在受限完成模式下的sanitize操作失败的情况下,在开始另一个sanitize操作之前:

  1.  1.使用退出失败模式动作发出的任何后续sanitize命令将以sanitize失败状态中止;
     2.在不受限制的完成模式下发出的任何sanitize命令将以sanitize失败的状态中止。
    

Identify Controller data structure 的Sanitize Capabilities字段指明:

  1.  1.支持的sanitize操作类型;
     2.是否在Sanitize bit后设置No-Deallocate(即..sanitize命令Dword 10bit9)在成功sanitize操作完成后导致数据被修改;
     3.控制器是否禁止Sanitize命令中的No-Deallocation After Sanitize位的功能。
    

如果sanitize命令选择了不支持的sanitize操作类型,那么控制器将以“Invalid Field”的状态中止该命令。

如果在NVM子系统中启用了任何 Persistent Memory Region,那么控制器将以禁用Persistent Memory Region的状态中止任何Sanitize命令。在启用持久内存区域时,禁止sanitize操作。

如果固件激活reset在pending期间,那么控制器将中止任何sanitize命令。

如果建立Firmware激活的Firmware Commit命令返回状态码为:

  1.  1.Firmware激活需要Controller级别reset;
     2.固件激活需要常规reset;
     3.固件激活需要NVM子系统reset。
    

则controller以同样的状态码abort sanitize命令。
如果返回的状态码不是以上这三种,
则controller以Firmware Activation Requires Controller Level Reset的状态码abort sanitize命令。

Sanitize操作期间禁止激活新的固件。(refer to section 8.15.1)

在Controller 内存缓冲区中支持的Sanitize命令(例如,Controller 内存缓冲区中的ASQ和ACQ)是特定于实现的。如果实现不支持Controller 中的Sanitize命令,且ASQ和ACQ存在于Controller 内存缓冲区中,那么Controller 将中止所有的Sanitize命令,状态为不支持CMB中存在命令。

所有的Sanitize操作(即块擦除,加密擦除和覆盖)是在后台执行。如果开始了Sanitize操作,那该命令就应该以成功完成收尾,如果结束状态不是成功,则Controller :

  1. 1.不得对该指令开始Sanitize操作;
    2.不得修改Sanitize Status log page;
    3.不得更改任何user data。

Sanitize命令使用Dword 10和Dword 11。保留所有其他与命令相关的字段。
1
2

Sanitize Operations (Optional)

Sanitize 操作会改变NVM子系统中的所有user data,这就意味着不可能从任何cache, the non-volatile media, or any Controller Memory Buffer中恢复之前的任何user data。

FW中的SQ/CQ是否被Sanitize 操作改变是具体实现的,存储在Controller Memory Buffers的所有其他数据都会被Sanitize 操作更改。

如果user data的一部分没有被更改,而sanitize操作成功完成,那么NVM子系统应确保该部分user data永久不可访问,以供未来在NVM子系统内使用(例如:从NVM媒体检索,缓存。或者Controller Memory Buffer)以及通过NVM子系统的任何接口(包括诸如NVMe-MI实现的管理接口)永久无法访问那部分用户数据。

sanitize操作的范围是NVM子系统的user data,包括caches, Persistent Memory Regions, and unallocated or deallocated areas of the media区域。sanitize操作不会影响Replay Protected Memory Block, boot partitions, or other media and caches(因为这些不会涉及到user data)。

sanitize操作还可以根据需要更改log page(例如,防止从log page信息派生user data)。一旦启动,sanitize操作将不能中止,并在Controller Level Reset(包括跨电源周期)后继续执行。有关sanitize操作的进一步信息,请参阅附件A。

Sanitize命令(见开头介绍)用于启动一个sanitize操作或从之前失败的sanitize操作中恢复。所有sanitize操作都在后台执行(即,sanitize命令的完成并不表示sanitize操作的完成)。sanitize操作的完成在sanitize状态log page中表示,log page包含sanitize操作完成的异步事件或sanitize操作以未预期的回收异步事件完成(如果有未完成的异步事件请求命令)。

Identify Controller数据结构的Sanitize Capabilities字段表示支持的Sanitize操作类型和特定于Sanitize操作的controller属性。
Sanitize操作类型有:

  1.  1.Block Erase: Sanitize操作通过一个low-level block erase方法来改变用户数据,该方法针对NVM子系统中存储user data的所有媒体位置;
     2.Crypto Erase:加密Sanitize操作通过改变NVM子系统中存储user data的媒体上所有位置的媒体加密密钥来改变user data;
     3.Overwrite:覆盖Sanitize操作通过将一个固定的数据pattern或相关的pattern一次或多次写入NVM子系统中可能存储user data媒体上的所有位置来改变user data。图484定义了写入的一个或多个数据pattern。
    

特定于Sanitize操作的controller属性有:

  1.  1.No-Deallocate Modifies Media After Sanitize (NODMMAS)字段表示在Sanitize操作成功完成后媒体是否被Controller修改,该操作在启动Sanitize操作的Sanitize命令中使用No-Deallocate After Sanitize设置为'1'。
     2.No-Deallocate禁用(NDI)位,表示Controller是否支持Sanitize命令中的No-Deallocate After Sanitize位。
    

Identify Controller数据结构中的NODMMAS字段(参见图251),指定如果一个Sanitize命令包含No-Deallocate After Sanitize设置为’1’并且NODMMAS设置为10b,那么一个Sanitize操作有一个相关的附加媒体修改操作。这个附加的媒体修改操作作用于请求的Sanitize操作的结果,目的是使所有LBA内容可读。有关Sanitize操作和与内部电路的相互作用的进一步信息,请参阅附件A

这个附加的媒体修改应该在以下情况前完成:

  1.  1.NVM子系统报告通过异步事件完成Sanitize(参见5.2节);
     2.NVM子系统在Sanitize状态日志中报告Sanitize完成情况(参见5.14.1.16.2节)。
    

Overwrite Sanitize操作是特定于媒体的,可能不适用于所有媒体类型。例如,如果媒体是NAND,多次传递Overwrite 操作可能会对媒体持久性产生不利影响。
Overwrite Mechanism

要启动一个sanitize操作,host提交一个指定sanitize操作类型之一的sanitize命令(即. .Block Erase, Overwrite, or Crypto Erase)。Host设置命令参数,包括Allow Unrestricted Sanitize Exit bit和No Deallocate After Sanitize bit。在验证Sanitize命令参数之后,controller将在后台启动Sanitize操作,更新Sanitize Status log page,然后以成功完成状态完成Sanitize命令。

如果Sanitize操作之后是相关附加介质的修改操作(参见图251中的NODMMAS),则相关的附加介质修改操作应在controller报告Sanitize操作完成之前完成。

如果Sanitize命令以Successful Completion以外的任何状态完成,那么controller将不会启动Sanitize操作,也不会更新Sanitize状态log page。

controller中忽略了SMART / Health
Information log page(例如,只读模式)的Critical Warning并试图完成Sanitize操作要求。当一个Sanitize操作正在进行中时,所有controller应中止未列在Figure 486的任何命令(参考8.15.1)。
3

在图485中指定了成功的sanitize操作所产生的user data值。
如果controller在成功完成sanitize操作后释放user data,那么从释放的逻辑块中读取的值将在6.7.1.1节中描述。
Host可以通过将Sanitize命令中的No Deallocate After Sanitize位设置为’1’来指定不释放。
4
Sanitize状态 log page(参见5.14.1.16.2节)包含Sanitize操作的 estimated times和关于最近开始的Sanitize操作的信息的一致性快照(包括Sanitize操作是否正在进行、Sanitize操作参数和最近的Sanitize操作的状态)。

如果Sanitize操作正在进行中,或相关的附加介质修改操作正在进行中,则controller应报告Sanitize操作正在进行中。如果Sanitize操作没有进行,则log page页中的Global Data deleted bit代表NVM子系统是否可能包含任何user data(即自最近一次成功的Sanitize操作以来未写入)

Sanitize状态log page应按照如下描述进行更新:

  1.  1.在NVM子系统中的任何controller就绪之前进行初始化;
     2.在Sanitize命令(启动一个Sanitize操作)完成之前进行更新(即,在Sanitize命令的完成CQ entry post之前);
     3.在Sanitize操作完成时进行更新(例如,在Sanitize操作完成异步事件的CQ entry post之前或Sanitize操作以Unexpected Deallocation asynchronous event完成之前)。
    

应该在Sanitize操作期间定期更新Sanitize状态log page,以使进度信息对host有效。

在Sanitize操作期间,host可能会定期检查sanitize Status log page以检查进度,但是,host应该限制这种轮询(例如,最多每几分钟一次),以避免干扰Sanitize操作本身的进度。

在Sanitize操作完成后:

  1.  1.如果Sanitize 操作成功,则 Global Data Erased bit应设为'1';
     2.更新了Sanitize Status日志页面;
     3.Sanitize命令完成一个AER命令(如果有一个未完成),controller会有以下动作:
     ①Log Page Identifier字段被设置为81h(即Sanitize Status);
     ②Asynchronous Event Information字段被设置为Sanitize 已完成或Sanitize 以Unexpected Deallocation asynchronous event完成(参见5.2节);
     ③Asynchronous Event Type字段设置为110b(即I/O Command Set specific status);
     4.NVM子系统中的所有controller都可以恢复Sanitize 操作开始时暂停的任何电源管理。
    

Host应该在完成Sanitize 操作(如果生成了异步事件,则clear)后读取Sanitize Status log page。

如果Sanitize 操作失败。NVM子系统中的所有controller都应该以Sanitize 失败(参见8.15.1节)的状态中止Sanitize 操作期间不允许的命令,直到后续的Sanitize 操作启动或成功从失败的Sanitize 操作中恢复。后续成功的Sanitize 操作或退出失败模式操作可用于从失败的Sanitize 操作中恢复。关于恢复的详细信息,请参阅5.24节。

如果支持Sanitize命令,那么NVM子系统和所有controller应该:

  1.  1.支持Sanitize状态日志页面;
     2.支持Sanitize操作Completed asynchronous event;
     3.如果Sanitize Config特性被支持,则支持Sanitize操作Unexpected Deallocation asynchronous event;
     4.支持Sanitize命令的退出失败模式操作;
     5.至少支持以下Sanitize操作类型之一:块擦除、覆盖或加密擦除;
     6.在Identify Controller数据结构中的sanitize Capabilities字段中指示对所有支持的sanitize操作类型;
    

The Sanitize Config Feature Identifier (refer to section 5.21.1.23)包含No-Deallocate Response
Mode bit,该bit指如果在Sanitize
Capabilities field of the Identify Controller
数据结构中的No-Deallocate Inhibited bit设为1,controller处理带No
Deallocate After Sanitize bit 的sanitize命令设为1的回应。
5

在NoDeallocate Error Response Mode模式下,controller以“Invalid Field in Command”的状态中止此类Sanitize 命令。在No-Deallocate Warning Response Mode模式下,controller将处理此类Sanitize命令。如果由此产生的Sanitize 操作成功完成,然后Sanitize Status log page 中Sanitize Status字段的2:0bit 设置为100b(参见图242)
6

Sanitize Command Restrictions

当执行Sanitize 操作时,当已经发生了一个失败的Sanitize 操作,但还没有成功地从失败中恢复时,NVM子系统中所有启用的controllers和namespaces都被限制只执行一组有限的操作。

在进行Sanitize 操作时:

  1.  1.NVM子系统中的所有controllers应该只处理Figure486中列出的Admin命令,受制于该图中声明的附加限制;
     2.所有I/O命令将以正在进行的Sanitize 状态中止;
     3.任何在Figure486中未明确允许的命令或命令选项,如果被NVM子系统中的任何controllers获取,将以Sanitize in Progress的状态中止;
     4.persistent Memory Region应被阻止被启用(即,setting PMRCTL.EN to ‘1’ does not result in PMRSTS.NRDY being cleared to ‘0’)。
    

当一个失败的Sanitize 操作发生时,后续的Sanitize 操作没有启动,也没有从失败的Sanitize 操作中成功恢复:

  1.  1.NVM子系统中的所有controllers都应该只处理Sanitize命令(参见5.24节)和Figure486列出的管理命令(受制于该图中注意到的附加限制);
     2.所有I/O命令将以Sanitize Failed状态abort;
     3.Sanitize命令允许有限制的操作(参见第5.24节);
     4.除了Sanitize命令之外,任何其他在Figure486中未显式允许的命令或命令选项,如果被NVM子系统中的任何controller获取,都将以Sanitize Failed的状态中止;
     5.persistent Memory Region应被阻止被启用(即,setting PMRCTL.EN to ‘1’ does not result in PMRSTS.NRDY being cleared to ‘0’)。
    

Admin Commands Allowed

GitHub 加速计划 / nv / nvm
78.06 K
7.82 K
下载
nvm-sh/nvm: 是一个 Node.js 版本管理器,用于在不同的 Node.js 版本之间进行切换。它可以帮助开发者轻松管理多个 Node.js 版本,方便进行开发和测试。特点包括轻量级、易于使用、支持跨平台等。
最近提交(Master分支:2 个月前 )
9c9ff4ba Moved issue template into ISSUE_TEMPLATE folder 13 天前
51ea809d - 13 天前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐