Wiping out a 160GB disk drive before dm-encrypt it

Rone · 2015-04-27 11:54:19

Hello arch users,

I'm new to the Forum.

It's the first time i have to encrypt a disk drive (it is an old 160GB disk drive) and here i need to _prepare_ it, wiping out (erasing) it's data first.
I read the wiki, trying to follow this method : https://wiki.archlinux.org/index.php/Dm … ic_methods

With "gdisk" command, i started in creating a new GUID partition table (GPT) on it, with only one partition taking the whole disk space ; the partition is on /dev/sda1 .

Then i issued those commands :

$ sudo cryptsetup open --type plain /dev/sda1 container

$ sudo dd if=/dev/zero of=/dev/mapper/container iflag=nocache oflag=direct

I don't know if it is a "problem", but as i'm posting, the "dd" command is still executing, and it's running for 6 hours now...

But this method says : "The following methods are specific for dm-crypt and are mentioned complementarily, because they are very *fast* and can be performed after a partition setup too."

It's not so fast as the wiki says, but probably i misunderstood something.

BTW i wanted to use the fastest method possible to "secure erasure" of the hard disk, before i use dm-crypt/LUKS tools to "format" the disk for encryption.

If you have an advice or any information, i'm interested to read you.

Rone

dice · 2015-04-27 12:07:24

You can check the progress of the dd command as described here.
The slow operation can have many reasons, e.g. slow HDD(you said it is an old one...), Slow CPU(or low entropy for encryption),...

EscapedNull · 2015-04-27 12:12:38

Old drives can be slow, since they are usually performing a lot of error correction and possibly sector relocation/indirection. Do this to check the progress of dd:

dd if=/dev/zero of=/dev/mapper/container iflag=nocache oflag=direct &
kill -SIGUSR1 %1 #run this command as many times as you wish

If it doesn't seem to be working properly, try some other methods. Note that the internal erase ATA command (using hdparm) is usually faster and also erases bad sectors, which dd does not.

Rone · 2015-04-27 12:27:38

Thanks a lot @dice and @EscapedNull for your comments.

I apologize because my post is not well formatted, i will improve that a bit later. --> That's ok now.
I think i will have to set the post now as RESOLVED ? --> Yes, i didn't find yet how to "edit" the post title, so i would be able to mark it as SOLVED in the future.

With your comments i could verify the progress of the dd command, and yes, it is very slow.

Reading your advice, i will consider others methods, beginning with hdparm i think.
I will compare those methods and know how many much they are faster.

So, in the tty running dd, i could observe the outputs of the two kill commands sent from another tty, that probably shows it is progressing (very ?) slowly :

$ sudo dd if=/dev/zero of=/dev/mapper/container iflag=nocache oflag=direct

108280133+0 records in
108280133+0 records out
55439428096 bytes (55 GB) copied, 27336.7 s, 2.0 MB/s
108541201+0 records in
108541201+0 records out
55573094912 bytes (56 GB) copied, 27402.6 s, 2.0 MB/s

I'm yet upgrading my system ; then i will install hdparm utility to follow the advice given above.

This blog post shows an example of the command :

 time hdparm --user-master u --security-erase pass /dev/sdX

Last edited by Rone (2015-04-27 13:39:44)

EscapedNull · 2015-04-27 15:53:18

I hope hdparm works for you! Also, it might be worth checking the drive's SMART health. If I were you, I'd keep backups of anything you put on that drive.

Last edited by EscapedNull (2015-04-27 15:55:47)

Rone · 2015-04-27 18:59:44

@EscapedNull, thanks for this notice about SMART health facility. Interesting for old drives like mine.

Now, hdparm is newly installed on my computer, and tomorrow i will be able to run it (for a relative long time i suppose). After this done, i will report here the result and total time used to process the command.

I expect this method will be fast enough, for example less than 3 hours to execute, because with dd command this would have taken around 12 hours to execute on my computer (PC Intel 2GHz Core2 CPU, 2 GB RAM) and my old disk .

Nice for your comments

Last edited by Rone (2015-04-27 19:49:46)

Rone · 2015-04-28 06:19:25

Concerning Secure Erase with hdparm i recommand this howto https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase , made by the kernel.org team.

I've just read this howto and now i'm ready to run the secure-erase command with hdparm.
This howto says

The security-erase command is a single command which typically takes minutes or hours to complete, whereas most ATA commands take milliseconds, or seconds to complete.

I didn't really understood the exact meaning of that statement, but i guess that means this method is fast enough.

and i launched this command that i think is displaying an estimation of the time to process an hdparm secure-erase with my disk drive :

# hdparm -I /dev/sda
(...)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: disabled
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
   Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
   Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
   * SMART feature set
   * Security Mode feature set
   * Power Management feature set
   * Write cache
   * Look-ahead
   * Release interrupt
   * Host Protected Area feature set
   * WRITE_BUFFER command
   * READ_BUFFER command
   * NOP cmd
   * READ/WRITE_DMA_QUEUED
      Advanced Power Management feature set
      Power-Up In Standby feature set
      SET_FEATURES required to spinup after power up
      Address Offset Reserved Area Boot
      SET_MAX security extension
      Automatic Acoustic Management feature set
   * 48-bit Address feature set
   * Device Configuration Overlay feature set
   * Mandatory FLUSH_CACHE
   * FLUSH_CACHE_EXT
   * SMART error logging
   * SMART self-test
   * General Purpose Logging feature set
Security:
Master password revision code = 65534
supported
enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
Security level high
88min for SECURITY ERASE UNIT.
(...)

I will launch the hdparm secure-erase and i will report the time used to complete.

Last edited by Rone (2015-04-28 06:26:22)

Rone · 2015-04-28 07:42:11

So, the command took around 1 hour to complete :

[root@pc ~ ]# time hdparm --user-master u --security-erase Eins /dev/sda
security_password="Eins"
/dev/sda:
Issuing SECURITY_ERASE command, password="Eins", user=user
real 64m6.527s
user 0m0.000s
sys 0m0.000s
[root@pc ~ ]#

Note that the PC became completely unresponsive for a long moment during this process, but i let the process run and finish ; and then the pc turn to be responsive again..

I will explore the SMART facility soon.

EscapedNull · 2015-04-30 16:20:19

Glad to see it work for you. The reason hdparm is faster than dd likely has to do with the fact that a secure internal erase means that the drive can blindly overwrite all bytes in sequential order. Using dd on the other hand, the drive may have to do some additional work/seeking in order to find a specific logical sector if it has been relocated. It might also be attempting to verify that the exact data the OS asked to be written was indeed written to the drive (although it's just encrypted pseudorandom data, the drive has no way of knowing that). A less likely but possible cause is that the machine was CPU-bound due to the encryption or lack of entropy.

A single zero pass (as in a secure internal erase) is theoretically less safe than a pseudorandom pass (as in dd->dm-crypt), but as soon as you begin filling up the filesystem on the drive, you'll be writing pseudorandom data anyway.

drcouzelis · 2015-04-30 17:46:38

Sorry, I don't know if this helps in the future but, I always just use the scrub command.

Rone · 2015-05-01 12:29:43

@drcouzelis, thanks i didn't know scrub tool, but was just aware about this type of secure erasing files on disk. There is also shred which does a thing similar, but is pre-installed on any Arch system :

$ pacman -Qo $(which shred)
/usr/bin/shred is owned by coreutils 8.23-1

EscapedNull wrote:

Old drives can be slow, since they are usually performing a lot of error correction and possibly sector relocation/indirection. Do this to check the progress of dd:
If it doesn't seem to be working properly, try some other methods. Note that the internal erase ATA command (using hdparm) is usually faster and also erases bad sectors, which dd does not.

@EscapedNull today when installing gnu/linux on a laptop, it turns out that the sata disk had sectors errors on it, so i remembered this quote above.
So i think i will have to fix bad sectors with hdparm. I read the man about the command and that is relative to --make-bad-sector, --repair-sector and --read-sector.
I also found this as an howto. Note that it uses SMART facility.
But i would have to read the wiki first, it probably ever explains how to repair (and/or erase ?) bad sectors.

Last edited by Rone (2015-05-01 12:38:47)

frostschutz · 2015-05-01 12:53:52

dd needs a larger blocksize, something in between bs=64k and bs=1M.

As an alternative there is also shred -v -n 1 for a single pseudorandom pass which is just as fast as dd'ing zeroes.

There are some strange things on that wiki page... it also mentions luks header size 1MB vs. 2MB depending on key size, I don't believe this is true... the header is slightly larger than 1MiB and the data offset is 2MiB simply for alignment reasons.

Last edited by frostschutz (2015-05-01 12:56:51)

Arch Linux

#1 2015-04-27 11:54:19

Wiping out a 160GB disk drive before dm-encrypt it

#2 2015-04-27 12:07:24

Re: Wiping out a 160GB disk drive before dm-encrypt it

#3 2015-04-27 12:12:38

Re: Wiping out a 160GB disk drive before dm-encrypt it

#4 2015-04-27 12:27:38

Re: Wiping out a 160GB disk drive before dm-encrypt it

#5 2015-04-27 15:53:18

Re: Wiping out a 160GB disk drive before dm-encrypt it

#6 2015-04-27 18:59:44

Re: Wiping out a 160GB disk drive before dm-encrypt it

#7 2015-04-28 06:19:25

Re: Wiping out a 160GB disk drive before dm-encrypt it

#8 2015-04-28 07:42:11

Re: Wiping out a 160GB disk drive before dm-encrypt it

#9 2015-04-30 16:20:19

Re: Wiping out a 160GB disk drive before dm-encrypt it

#10 2015-04-30 17:46:38

Re: Wiping out a 160GB disk drive before dm-encrypt it

#11 2015-05-01 12:29:43

Re: Wiping out a 160GB disk drive before dm-encrypt it

#12 2015-05-01 12:53:52

Re: Wiping out a 160GB disk drive before dm-encrypt it

Board footer