1

I stumbled upon this while trying to wipe my whole disk using plain dm-crypt as suggested, e.g., here (arch linux wiki):

# cryptsetup open --type plain -d /dev/urandom /dev/sda to_be_wiped
# dd if=/dev/zero of=/dev/mapper/to_be_wiped status=progress

EDIT: See below, I checked that everything is set up correctly

I checked the first few bytes of my disk /dev/sda and found some old data on it, so I tried the following (after having run the above dd command for 2 hours):

A.1 Wiping the first part of the disk manually using /dev/zero:

dd if=/dev/zero of=/dev/sda bs=512 count=2

A.2 Reading the first part of the disk to verify it's zeroed. It is:

dd if=/dev/sda bs=512 count=2 | xxd

A.3 Reading the first part of the mapped device. (This seemed to be zeroed as well - WHY? shouldn't this be the "decrypted zeroes"?)

dd if=/dev/mapper/to_be_wiped bs=512 count=2 | xxd

After that, I did the following:

B.1 Zeroing the mapped device /dev/mapper/to_be_wiped:

dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=512 count=2

B.2 Reading /dev/sda as A.2 above - still zeroes (WHY? shouldn't this be the encrypted zeroes, i.e. random data?).

B.3 Reading the encrypted device as A.3 above - also zeroes (as expected).

Even syncing doesn't change the result for my hdd. So I tried the same on a file. Here everything seems to work as expected. So I am wondering...


My (main) question is:

  1. Where is my error, am I doing something wrong? I assumed a sector-by-sector encryption, so that in the first case 3. shouldn't be zeroed, while in the second case 2 should be randomized.

This automatically and inevitably leads to the follow-up question

  1. Is it even safe then to assume you can securely wipe a disk using this method?

What could help on the way to get there:

  • Isn't the mapping of a plain dm-crypt device sector by sector, as stated in the manual?
  • Is there a difference between using a file for dm-crypt rather than a disk?

EDIT: I verified, as suggested by Xen2050, that everything is set up correctly:

# cryptsetup -v status to_be_wiped 
/dev/mapper/to_be_wiped is active.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  key location: dm-crypt
  device:  /dev/sda
  sector size:  512
  offset:  0 sectors
  size:    976773168 sectors
  mode:    read/write
Command successful.

# dmsetup ls --target crypt
to_be_wiped (254, 0)

# lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0           7:0    0 487.9M  1 loop  /run/archiso/sfs/airootfs
sda             8:0    0 465.8G  0 disk  
└─to_be_wiped 254:0    0 465.8G  0 crypt 
[...]

The loop device is from the arch linux live stick I use, I removed the other present disks from lsblk.

EDIT2: Short example with output added (below). Is dm-crypt not writing to disk if one does not close it? If so, why and how to change it? Have a look at the following:

root@archiso ~ # dd if=/dev/zero of=/dev/sda bs=8 count=2 status=none
root@archiso ~ # xxd -l 16 /dev/sda                                  
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # cryptsetup open --type plain -d /dev/urandom /dev/sda to_be_wiped
root@archiso ~ # xxd -l 16 /dev/mapper/to_be_wiped                                
00000000: df52 0cc9 082a 0de2 1df7 b55f 7626 c45b  .R...*....._v&.[
root@archiso ~ # dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=8 count=1 status=none 
root@archiso ~ # xxd -l 16 /dev/mapper/to_be_wiped                                  
00000000: 0000 0000 0000 0000 1df7 b55f 7626 c45b  ..........._v&.[
root@archiso ~ # xxd -l 16 /dev/sda               
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # sync   
root@archiso ~ # grep -e Dirty: -e Writeback /proc/meminfo 
Dirty:                 0 kB
Writeback:             0 kB
WritebackTmp:          0 kB
root@archiso ~ # cat /sys/dev/block/8:0/stat
    1153        0    49276    19035        9        0       72     6763        0    19010    25747        0        0        0        0
root@archiso ~ # xxd -l 16 /dev/sda  
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # cryptsetup close to_be_wiped                                     
root@archiso ~ # xxd -l 16 /dev/sda
00000000: c6d2 1e9b abf4 16a2 7d1a b1bd 8a28 63d8  ........}....(c.

EDIT3: I did a similar test as in EDIT2 with more data and found the following: It seems that plain dm-crypt is not writing the first half megabyte unless closed. If I close the mapped device (cryptsetup close to_be_wiped), everything is randomized. Weird stuff without any explanation, especially because files seem to be handled correctly/immediately - does anyone have one?

EDIT4: I used cryptsetup 2.0.6 on the arch iso 2019.02.01 from February.

0

3 Answers 3

1

The first commands should have worked, they're the same as the cryptsetup faq too (2.19). Using a file instead of a device uses an intermediary loop file, but is otherwise the same.

But I'm suspecting there was an error with the mapped device name. dd will happily create a new file in /dev/mapper/ if none exists, and it appears nothing was being written to your hard drive.

  • What's in the folder now, as in ls -al /dev/mapper/?
  • After running the initial cryptsetup command, did you verify with:

    • sudo cryptsetup -v status to_be_wiped
    • sudo dmsetup ls --target crypt
    • lsblk
  • Did you monitor the hard drive to see if anything was actually being written by the first dd (using a system monitor that differentiates between writes to your sda drive, and /, I know conky can)? Was the sda drive or your system drive making any noises or lighting up, if it's noticeable?

[Just wondering, but sda isn't your system drive, is it?]

In your first 3. question (FYI the question numbering is problematic, there are three separate "2."'s) you had just written zeros to the start of sda, so reading back zeros is expected.

In your second example, dd is trying to write to /dev/mapper and not a file inside, but that should have errored out with dd: failed to open '/dev/mapper': Is a directory so I'm assuming that's a typo in the Q.


After updates EDIT2 & 3

Hmm, everything looks like it should have worked, but just doesn't... afaik cryptsetup's close command isn't supposed to write anything (just "forget" the key & stop encrypt/decrypting). Only vaguely related, but LUKS usually reserves the first 1M or 2M if it's using a header there.

Starting to look like a bug in something... I'd try a different live ISO / kernel / distribution to at least narrow down if it's just that particular live ISO, or your drive.

3
  • It's no error with the device name. In the folder is /dev/mapper/control and /dev/mapper/to_be_wiped (next to . and .. ofc). I verified it works, I will post the results in my question soon. I did not monitor the hard drive directly, I just watched /proc/meminfo which indicated a huge writing process while wiping for 2h.
    – nox
    Mar 10, 2019 at 16:44
  • Indeed, it was a typo. And it was a system drive, I use a live usb drive to perform the wipe. Also, I created new labels now, to make referencing easier.
    – nox
    Mar 10, 2019 at 16:45
  • By now I found that the particular cryptsetup version indeed has a bug regarding command line options (I could not create luks2 containers with custom hash algorithm or key size). I had to update it. I'll check what version and kernel this live ISO provides and post in my question. I installed a new system on the drive (sda), so I can't retest (easily) anymore. Nevertheless I found the plain mode working if I discard the cache of the mapped device/sda. So it is probably just a caching issue. I'll post a longer explanation in an answer as soon as I can find the time. Thanks for your help!
    – nox
    Mar 11, 2019 at 20:57
1

This seems to be a caching issue, as the following shows:

root@archiso ~ # dd if=/dev/zero of=/dev/sda bs=32 count=2 % zeroing sda
2+0 records in
2+0 records out
64 bytes copied, 0.75095 s, 0.1 kB/s
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % verify result
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # cryptsetup open --type=plain -d /dev/urandom /dev/sda to_be_wiped % open as plain dm-crypt
root@archiso ~ # dd if=/dev/mapper/to_be_wiped bs=32 count=2 status=none | xxd  % show to_be_wiped
00000000: 747a 1b84 3847 b8f2 7bae ec41 a302 05d2  tz..8G..{..A....
00000010: c866 4305 7293 4765 99eb c88b a0da 2548  .fC.r.Ge......%H
00000020: c866 4305 7293 4765 99eb c88b a0da 2548  .fC.r.Ge......%H
00000030: c866 4305 7293 4765 99eb c88b a0da 2548  .fC.r.Ge......%H
root@archiso ~ # dd if=/dev/zero bs=32 count=2 of=/dev/mapper/to_be_wiped % zeroing to_be_wiped
2+0 records in
2+0 records out
64 bytes copied, 0.749869 s, 0.1 kB/s
root@archiso ~ # dd if=/dev/mapper/to_be_wiped bs=32 count=2 status=none | xxd % verify result
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % sda should be randomized, check that
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
root@archiso ~ # dd of=/dev/sda oflag=nocache conv=notrunc,fdatasync count=0 % since sda is not randomized, drop cache manually
0+0 records in
0+0 records out
0 bytes copied, 0.000501071 s, 0.0 kB/s
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % check sda again
00000000: 077d 0039 4781 2f67 a50c 413f 8ad7 b06d  .}.9G./g..A?...m
00000010: 99b2 2517 04cc 04e6 69a5 e806 44ba f902  ..%.....i...D...
00000020: 4208 ff50 72d7 225b e0ce 0346 a1c6 3ac0  B..Pr."[...F..:.
00000030: fab3 b9f9 5218 faf3 4392 50ad 8c71 1f37  ....R...C.P..q.7

So, after discarding the cache, the randomized data is shown. I don't know why the cache is dropped after issuing cryptsetup close though.

0

I ran into a similar issue with cryptsetup plain-wipe. It seemed to leave partition table of the drive intact, according to lsblk.

hdparm -z seem to have fixed it, though I'm not sure how.

-z     Force a kernel re-read of the partition table of the specified device(s).

It was a Seagate 2TB, probably with SMR.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .