Secure erase is a mechanism, available in most Solid-State Drives (SSDs), allowing users to “sanitize”— completely erase—all the stored data within the device. A secure erase operation is performed internally to the device because the host can only address the logical blocks, not the physical blocks within the media. Additionally, the accessible capacity seen by the operating system is usually smaller than the internal physical capacity of the device. SSDs, for example, significantly overprovision capacity, especially enterprise-class ones, to avoid performance penalties during garbage collection, wear leveling, and map out bad blocks for fault tolerance.
Intel® Optane™ persistent memory (PMem) supports secure erasure in the form of cryptographic erasure. Intel Optane PMem secures data using encryption at rest, which means we can perform a cryptographic erasure by changing the encryption key—stored within the modules. By doing this, we are not so much deleting the data but we are making it inaccessible. In addition to cryptographic erasure, Intel Optane PMem also allows users to overwrite the whole device with zeros (encrypted zeros). Cryptographic erasure is much faster than physically writing random data across the entire device, known as overwriting. We can also combine both to get the most definite form of sanitation.
Secure erasure is important for a variety of reasons. For example, to ensure data is not leaked if a storage device is reprovisioned or sold to a third party. But even if we do not plan ever to reprovision a device, regulations—such as the European Union Lot 9 requirements—mandate us to always include secure erasure with our storage products. Regarding Lot 9, requirement 1.2.2 states:
"1.2.2. From 1 March 2020, a functionality for secure data deletion shall be made available for the deletion of data contained in all data storage devices of the product."
The rest of this article will describe how to sanitize PMem modules from different levels of the system’s hierarchy.
Many server OEMs provide a sanitize operation within the BIOS menu options. Sometimes we see these options provided in the context of a factory reset for the whole system. Other times, the function is explicitly available for specific devices such as SSDs or Non-Volatile Memory (NVM) devices, and therefore won’t work for Intel Optane PMem devices. Check your server BIOS documentation to verify the feature exists and how to perform a secure erase operation within the BIOS.
From the UEFI shell, we can use the ipmctl tool to sanitize Intel® Optane™ persistent memory modules. The ipmctl delete -dimm command uses a cryptographic erasure procedure across all PMem modules in the system:
FS0:\> ipmctl delete -dimm
The command will fail if there are any configured namespaces. If that is the case, destroying them first is necessary. You can destroy all the configured namespaces by destroying all labels:
FS0:\> ipmctl delete -f -dimm -pcd
It is also possible to pass a comma-separated list of module IDs (dimms in ipmctl’s terminology):
FS0:\> ipmctl delete -dimm 0x0101,0x0111
You can get the IDs by running ipmctl show -dimm
Sanitizing only a subset of PMem modules, however, is not recommended, as it may put the system in an undesirable state. The reason is that, for the current generation of Intel Optane PMem, only one encryption key is allowed to be used for all the modules installed in the system. Sanitizing a subset of modules, however, can help when some modules can’t be sanitized due to being “busy”. If the command to delete all fails, you can delete a subset of modules first and try again.
If you have set a passphrase, you will need to pass it to the command as well:
FS0:\> ipmctl delete -dimm Passphrase=******
A passphrase, used to lock the current key, is needed to protect your data from anyone with physical access to your server. Without a passphrase, the encryption key provides cryptographic erasure and nothing else. This is how memory mode implements the illusion of volatility (by changing the encryption key during every power cycle or reboot). If you want to learn more about Intel Optane PMem security management using ipmctl, refer to the Security section in the IPMCTL User Guide.
Finally, sending an overwrite command to the PMem modules is not supported in ipmctl at the UEFI level. Fortunately, it is supported at the operating system (OS) level by other tools.
Although ipmctl is available for both Linux* and Windows*, the secure erasure features are not implemented at the OS level, as ipmctl does not interact with the driver’s security implementation. This interaction is necessary to ensure no data is leaked if dirty cache lines are written back to PMem (by being evicted/flushed) after a secure erasure completes. The driver ensures no data is leaked by issuing a WBINVD instruction before and after the operation.
# ndctl destroy-namespace -f all destroyed 2 namespaces # ndctl disable-region all disabled 2 regions # ndctl sanitize-dimm all --crypto-erase --zero-key sanitized 12 nmems.
In contrast to the ipmctl case, using a passphrase is the default behavior in ndctl. If no passphrase is provided, the option --zero-key should be used as shown above.
This command securely erases the data, metadata, and info-blocks, but it does not modify namespace labels. Any existing namespaces and regions associated with the affected modules will need to be inactive (disabled) or destroyed before running the sanitation command. That is why destroy-namespace and disable-region are run before sanitize-dimm above.
When namespaces are enabled after having been disabled, they are left in raw mode. It is possible to reconfigure a raw namespace to any of the other modes with the option -e. For more information about how to disable, enable, and reconfigure namespaces and regions, refer to the Managing Regions and Managing namespaces pages from the NDCTL User Guide.
As with the ipmctl case, we can sanitize one or more modules by passing their IDs separated by spaces:
# ndctl sanitize-dimm nmem0 nmem1 nmem6 --crypto-erase --zero-key
You can get IDs by running ndctl list -D.
To issue an overwrite command, we run:
# ndctl sanitize-dimm all --overwrite --zero-key
Note This will take a significant amount of time.
Note Overwrite will only work in 100% app-direct configurations. Overwrite isn’t possible when part of the capacity is being used as main memory by the OS, because the overwrite operation applies to the entire device capacity. For more information about how to configure Intel Optane PMem, refer to our Quick Start Guide: Provision Intel Optane Persistent Memory.
The overwrite command will run asynchronously in the background. You can actively wait for the command to finish running:
# ndctl wait-overwrite all
Overwrite deletes not only the data area, but also the label area, thus erasing any record of the namespaces configured on the PMem.
It is also possible to use both options—crypto erase and overwrite—in the same command invocation. In this situation, a crypto erase is performed before overwriting:
# ndctl sanitize-dimm all --crypto-erase --overwrite --zero-key
Finally, it is important to point out that, if a passphrase is set on the PMem, after completion of the sanitize-dimm command, the passphrase is disabled. To enable security again, a new passphrase will need to be set. To learn more about Intel Optane PMem security management using ndctl, refer to the Managing NVDIMM Security section from the NDCTL User Guide.
In this article, we described what secure erasure is, why it is important (for example, to meet the latest regulations in this area imposed by the European Union), and demonstrated how this can be accomplished for Intel Optane persistent memory from the BIOS, UEFI shell, and operating system.
Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. Check with your system manufacturer or retailer or learn more at intel.com.
No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.
Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps.
The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request.
Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm.
This sample source code is released under the Intel Sample Source Code License Agreement.
Intel, the Intel logo, Intel Optane, and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries.
*Other names and brands may be claimed as the property of others.
© 2020 Intel Corporation
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804