SSD Secure Erase
In this article, we will show you how to perform a secure erase on a SSD under Linux. By doing this, you can increase the performance of frequently used SSDs for future use. But, all of the data will be lost. For Fusion-io’s ioDrives, see Low-level Formatting a Fusion-io ioDrive.
Update as of August 2011: Because an ATA trim will be performed by NTFS with Windows 7 or when formatting using Ext4 from mke2fs 1.41.10 or XFS from xfsprogs 3.1.0, the secure erase procedure is no longer necessary in these cases (see Goal of a Secure Erase below). If the spare area should be increased for a used SSD (such as by means of SSD Over-provisioning using hdparm), it is still reasonable to delete all blocks before increasing the size of the spare area (which is something like performing a format including trim across the entire disk capacity, or with a secure erase).
Goal of a Secure Erase
According to the ATA specification, a secure erase should guarantee the secure erasure of all stored data on a storage medium. Most SSDs support secure erase, executing it for the physical deletion of all blocks on the SSD. The SSD will then be usable at its original ideal performance level, since all pages can be written directly (see Solid State Drive - Writing).
For the newer SSDs with integrated encryption, secure erase may be implemented differently. Such SSDs automatically encrypt all data that has been written. Deleting the key would be sufficient to for a secure erase; the data could then no longer be decrypted, but would still physically exist. When asked at the end of the Optimizing Solid-State Drive (SSD) Performance for Data Center Applications session at Intel Developer Forum 2011, Tahmid Rahman, Intel Senior Technical Marketing Engineer, informed us that the Intel 320 Series SSDs and Intel 710 Series SSDs with integrated encryption would also continue to delete the flash blocks despite this ability to delete only the key. The primary reason is that a secure erase should return performance to its initial state even with these SSDs. For Sandisk SSDs the behavior is differnt, a Secure Erase does not erase all NAND.
For other SSDs with integrated encryption, which do not sufficiently document the behavior of a secure erase, deleting the SSD blocks using trim would be recommended in addition to a secure erase, in order to get the ideal performance for re-use of the SSDs. Windows 7 automatically performs a trim when formatting, as do the Ext4 from mke2fs 1.41.10 and XFS from xfsprogs 3.1.0.
The hdparm tool for Linux provides an additional option, however the man page advises against using the option with hdparm version 9.27 (Ubuntu 10.10):
--trim-sector-ranges For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!! Tells the drive firmware to discard unneeded data sectors, destroying any data that may have been present within them. This makes those sectors available for immediate use by the firmware's garbage collection mechanism, to improve scheduling for wear-leveling of the flash media. This option expects one or more sector range pairs immediately after the flag: an LBA starting address, a colon, and a sector count, with no intervening spaces. EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!! E.g. hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz
Steps necessary for a Secure Erase
We have taken the following steps from the ATA wiki at kernel.org. In the example, the SSD to be deleted has the device name /dev/sdb. If you want to perform a secure erase, pay special attention to the correct device name, so that you will not erroneously delete the wrong drive.
Important Note: Only execute a secure erase when running the SSD directly from a SATA port, since problems may arise otherwise.
Step 1: NOT Frozen
In the first step, check if the SSD is in the
not frozen state and support SSD Secure Erase (supported: enhanced erase):
root@ubuntu-10-04:~# hdparm -I /dev/sdb /dev/sdb: ATA device, with non-removable media Model Number: INTEL SSDSA2M160G2GC Serial Number: CVPO014602FC160AGN Firmware Revision: 2CV102HD Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6 [...] Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. [...]
Step 2: Set the User Passwords
So that you can execute a secure erase, you must first define a user password. In the example, we have used the password,
Eins. The security feature will be enable thereafter.
Warning: If you set the user password, the SSD will entire the locked state after re-booting. The SSD will then block all normal access until it is re-locked with the correct password. However, if you perform the additional steps completely (without re-booting), the security feature will be automatically deactivated.
root@ubuntu-10-04:~# hdparm --user-master u --security-set-pass Eins /dev/sdb security_password="Eins" /dev/sdb: Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high root@ubuntu-10-04:~# hdparm -I /dev/sdb [...] Security: Master password revision code = 65534 supported enabled not locked not frozen not expired: security count supported: enhanced erase Security level high 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. [...]
Step 3: Secure Erase
Now, execute the secure erase procedure:
root@ubuntu-10-04:~# time hdparm --user-master u --security-erase Eins /dev/sdb security_password="Eins" /dev/sdb: Issuing SECURITY_ERASE command, password="Eins", user=user real 0m55.408s user 0m0.000s sys 0m0.000s root@ubuntu-10-04:~#
Step 4: Checking
After the secure erase procedure has completed, the SSD security feature will be disabled.
root@ubuntu-10-04:~# hdparm -I /dev/sdb [...] Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. [...]
- The Intel SSD 320 Review: 25nm G3 is Finally Here: TRIM Performance (anandtech.com): A side effect of having all data encrypted on the NAND is that secure erases happen much quicker. You can secure erase a SF drive in less than three seconds as the controller just throws away the encryption key and generates a new one. Intel's SSD 320 takes a bit longer but it's still very quick at roughly 30 seconds to complete a secure erase on a 300GB drive. [...] Without the encryption key, the data stored in the NAND array is meaningless.
- What is the difference between Secure Erase and Sanitize? (kb.sandisk.com)
Author: Werner Fischer
Werner Fischer, working in the Web Operations & Knowledge Transfer team at Thomas-Krenn, completed his studies of Computer and Media Security at FH Hagenberg in Austria. He is a regular speaker at many conferences like LinuxTag, OSMC, OSDC, LinuxCon, and author for various IT magazines. In his spare time he enjoys playing the piano and training for a good result at the annual Linz marathon relay.