Difference between revisions of "SSD memory cell clearing"

From ArchWiki
Jump to: navigation, search
(4m is faster than 8k)
(Step 3 - Issue the ATA Secure Erase command: Should be security-erase-enhanced)
 
(31 intermediate revisions by 14 users not shown)
Line 1: Line 1:
 
[[Category:Storage]]
 
[[Category:Storage]]
{{Article summary start}}
+
{{Related articles start}}
{{Article summary text|This article presents a method to reset all cells on an SSD to their factory default state thus recovering any loss of write performance.}}
+
{{Related|Solid State Drives}}
{{Article summary heading|Related Articles}}
+
{{Related|Securely wipe disk}}
{{Article summary wiki|Solid State Drives}}
+
{{Related articles end}}
{{Article summary wiki|Securely Wipe HDD}}
+
{{Article summary end}}
+
 
+
== Introduction ==
+
 
+
 
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.
 
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.
{{Warning|Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!}}
 
  
== tl; dr ==
+
{{Warning|
 +
* Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!
 +
* Do '''not''' proceed with this if the target drive isn't connected directly to a SATA interface. Issuing the Secure Erase command on a drive connected via USB or a SAS/RAID card could potentially brick the drive!}}
  
{{Warning|It is recommended that you read the rest of the article BEFORE you try this!}}
+
{{Note|Following information has been taken from the official ATA wiki page[https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase].}}
+
dcfldd if=/dev/zero of=/dev/sdX bs=4m
+
hdparm --user-master u --security-set-pass Eins /dev/sdX
+
hdparm --user-master u --security-erase Eins /dev/sdX
+
  
== Step 0 ==
+
== Step 1 - Make sure the drive security is not frozen ==
{{warning|Triple check that the correct drive designation is used in the dcfldd step; '''THERE IS NO TURNING BACK ONCE THE ENTER KEY HAS BEEN PRESSED!''' You have been warned.}}
+
  
Optionally write zeros to every block on the SSD using either {{ic|dd}} or {{ic|dcfldd}}:
+
Issue the following command:
  dcfldd if=/dev/zero of=/dev/sdX bs=4m
+
  
Depending on the size and speed of the SSD, this step may take some time. A very nice feature of {{ic|dcfldd}} is the level of verbosity it uses by default. It will report the current amount of data written to the device. Users can approximate how long the process will take based on this output.
 
 
== Step 1 - Make sure the drive security is not frozen ==
 
Issue the following command:
 
 
  # hdparm -I /dev/sdX
 
  # hdparm -I /dev/sdX
  
If the command output shows "frozen" one cannot continue to the next step. Most BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.
+
If the command output shows "frozen" one cannot continue to the next step. Some BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.
  
A possible solution for SATA drives is hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables.
+
A possible solution is to simply suspend the system.  Upon waking up, it is likely that the freeze will be lifted.  If unsuccessful, one can try hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables. If hot-(re)plugging of SATA cables still crashes the kernel, make sure that AHCI is enabled in the BIOS (AHCI allows hot-(re)plugging operations without a crash). Using a USB-to-SATA adapter is an option if it supports hotplugging. One can also use {{Pkg|hdparm}} via USB.
  
* It has been reported that hooking up the drive to an eSATA SIIG ExpressCard/54 with an eSATA enclosure will leave the drive security state to "not frozen".
+
== Step 2 - Enable security by setting a user password ==
* Placing the target system into "sleep" (Clevo M865TU notebook, Fujitsu T2010 notebook, Dell XPS M1330, Lenovo ThinkPad x220, Samsung NC10) and waking it up again has been reported to work as well; this may reset drives to "not frozen". In case you are booting from USB, you need a distribution, that runs entirely in RAM, like [http://grml.org Grml], see the {{ic|grml2ram}} option. Run {{ic|echo -n mem > /sys/power/state}} to set the computer to sleep.
+
* Hooking up the drive to a USB 2/3 port does '''NOT''' work, as you need to issue IDE commands, which is only possible via IDE/SATA connection.
+
* Make sure drive security is '''disabled''' in BIOS, so no password is set:
+
  
<pre>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.</pre>
 
 
== Step 2 - Enable security by setting a user password ==
 
 
{{Note|When the user password is set the drive will be locked after next power cycle denying normal access until unlocked with the correct password.}}
 
{{Note|When the user password is set the drive will be locked after next power cycle denying normal access until unlocked with the correct password.}}
 +
{{Warning|If you have a Lenovo laptop, do '''not''' reboot it after this step. Certain variants of Lenovo's BIOS are susceptible to use a deviating algorithm for calculating the encryption key. After startup the machine will not be able to connect the SSD drive.[https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/]}}
  
Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is "Eins" as shown:
+
Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is "PasSWorD" as shown:
  # hdparm --user-master u --security-set-pass Eins /dev/sdX
+
 
  security_password="Eins"
+
  # hdparm --user-master u --security-set-pass PasSWorD /dev/sdX
 +
  security_password="PasSWorD"
 
  /dev/sdX:
 
  /dev/sdX:
  Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
+
  Issuing SECURITY_SET_PASS command, password="PasSWorD", user=user, mode=high
  
 
As a sanity check, issue the following command
 
As a sanity check, issue the following command
Line 65: Line 39:
  
 
The command output should display "enabled":
 
The command output should display "enabled":
<pre> Security:  
+
{{bc|1=Security:  
 
         Master password revision code = 65534
 
         Master password revision code = 65534
 
                 supported
 
                 supported
Line 74: Line 48:
 
                 supported: enhanced erase
 
                 supported: enhanced erase
 
         Security level high
 
         Security level high
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.</pre>
+
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
 +
}}
  
 
== Step 3 - Issue the ATA Secure Erase command ==
 
== Step 3 - Issue the ATA Secure Erase command ==
  
# time hdparm --user-master u --security-erase Eins /dev/sdX
+
The final step is to issue the secure erase command, instructing the device's bios to erase its contents. Note for the device used in this example, earlier output states:
  
Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD (for a 1TB hard disk it could take up to 3 hours).
+
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
  
  security_password="Eins"
+
As per ATA specification the ''enhanced'' security erase ({{ic|--security-erase-enhanced}}) performs a more elaborate wipe. If the estimated completion time for both commands is equal, it indicates the drive manufacturer shortcut the specification and uses the same erase function for both. A short time (like 2 minutes) in turn indicates the device is self-encrypting and its bios function will wipe the internal encryption key instead of overwriting all data cells.[http://security.stackexchange.com/questions/62253/what-is-the-difference-between-ata-secure-erase-and-security-erase-how-can-i-en]
 +
 
 +
{{warning|Triple check that the correct drive designation is used. There is '''no turning back''' once the command is confirmed. You have been warned.}}
 +
 
 +
# hdparm --user-master u --security-erase PasSWorD /dev/sdX
 +
 
 +
Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.
 +
 
 +
  security_password="PasSWorD"
 
  /dev/sdX:
 
  /dev/sdX:
  Issuing SECURITY_ERASE command, password="Eins", user=user
+
  Issuing SECURITY_ERASE command, password="PasSWorD", user=user
 
  0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w
 
  0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w
  
 
The drive is now erased. After a successful erasure the drive security should automatically be set to disabled (thus no longer requiring a password for access). Verify this by running the following command:
 
The drive is now erased. After a successful erasure the drive security should automatically be set to disabled (thus no longer requiring a password for access). Verify this by running the following command:
 +
 
  # hdparm -I /dev/sdX
 
  # hdparm -I /dev/sdX
  
 
The command output should display "not enabled":  
 
The command output should display "not enabled":  
<pre> Security:  
+
{{bc|1=Security:  
 
         Master password revision code = 65534
 
         Master password revision code = 65534
 
                 supported
 
                 supported
Line 99: Line 83:
 
         not    expired: security count
 
         not    expired: security count
 
                 supported: enhanced erase
 
                 supported: enhanced erase
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.</pre>
+
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
 +
}}
  
 
== Tips ==
 
== Tips ==
See the [[GRUB_EFI_Examples]] for hardware-specific instructions to get GRUB EFI working following a wipe.
+
 
 +
See the [[GRUB EFI Examples]] for hardware-specific instructions to get GRUB EFI working following a wipe.

Latest revision as of 21:32, 2 April 2016

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

Warning:
  • Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!
  • Do not proceed with this if the target drive isn't connected directly to a SATA interface. Issuing the Secure Erase command on a drive connected via USB or a SAS/RAID card could potentially brick the drive!
Note: Following information has been taken from the official ATA wiki page[1].

Step 1 - Make sure the drive security is not frozen

Issue the following command:

# hdparm -I /dev/sdX

If the command output shows "frozen" one cannot continue to the next step. Some BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.

A possible solution is to simply suspend the system. Upon waking up, it is likely that the freeze will be lifted. If unsuccessful, one can try hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables. If hot-(re)plugging of SATA cables still crashes the kernel, make sure that AHCI is enabled in the BIOS (AHCI allows hot-(re)plugging operations without a crash). Using a USB-to-SATA adapter is an option if it supports hotplugging. One can also use hdparm via USB.

Step 2 - Enable security by setting a user password

Note: When the user password is set the drive will be locked after next power cycle denying normal access until unlocked with the correct password.
Warning: If you have a Lenovo laptop, do not reboot it after this step. Certain variants of Lenovo's BIOS are susceptible to use a deviating algorithm for calculating the encryption key. After startup the machine will not be able to connect the SSD drive.[2]

Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is "PasSWorD" as shown:

# hdparm --user-master u --security-set-pass PasSWorD /dev/sdX
security_password="PasSWorD"
/dev/sdX:
Issuing SECURITY_SET_PASS command, password="PasSWorD", user=user, mode=high

As a sanity check, issue the following command

# hdparm -I /dev/sdX

The command output should display "enabled":

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 - Issue the ATA Secure Erase command

The final step is to issue the secure erase command, instructing the device's bios to erase its contents. Note for the device used in this example, earlier output states:

2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

As per ATA specification the enhanced security erase (--security-erase-enhanced) performs a more elaborate wipe. If the estimated completion time for both commands is equal, it indicates the drive manufacturer shortcut the specification and uses the same erase function for both. A short time (like 2 minutes) in turn indicates the device is self-encrypting and its bios function will wipe the internal encryption key instead of overwriting all data cells.[3]

Warning: Triple check that the correct drive designation is used. There is no turning back once the command is confirmed. You have been warned.
# hdparm --user-master u --security-erase PasSWorD /dev/sdX

Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.

security_password="PasSWorD"
/dev/sdX:
Issuing SECURITY_ERASE command, password="PasSWorD", user=user
0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w

The drive is now erased. After a successful erasure the drive security should automatically be set to disabled (thus no longer requiring a password for access). Verify this by running the following command:

# hdparm -I /dev/sdX

The command output should display "not enabled":

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.

Tips

See the GRUB EFI Examples for hardware-specific instructions to get GRUB EFI working following a wipe.