5

The command lsblk returns the following output that lists 4 partitions.

sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0     8M  0 part 
├─sda2   8:2    0    40G  0 part /
├─sda3   8:3    0 883.8G  0 part /home
└─sda4   8:4    0   7.7G  0 part [SWAP]

When executing one or more of the following commands, is the necessary to delete the partitions prior?

If no, why and if yes, why?

If partitions are not deleted prior to the commands below being run, what is the risk of data remanence?

When executing one or more of the commands below, the partitions are not deleted. 

dd if=/dev/urandom of=/dev/sda bs=2MB conv=fsync
hdparm --user-master u --security-erase password /dev/sda
pv /dev/urandom > /dev/sda
Improve this question
2
  • 1
    Are you sure the partitions aren't deleted? How did you check? Maybe take a look at partprobe? – AndrolGenhald Dec 26 '18 at 20:21
  • According to this answer you should long-format the drive anyway. And that will remove any partitions anyway AFAIK. – User42 Dec 27 '18 at 12:34
4

What you are seeing is a cached view of the previous partitions.

If they appear to persist even after a wipe, this is a result of the kernel caching the last known partition table in memory. It does this because it does not expect the layout to change at runtime, so rather than re-read the table each time the partition layout is queried, it reads it once at boot. If you want to force it to re-read the partition table, you can run a command like partprobe, reconnect the drive, or reboot.

The partitioning information is contained in the partition table, which is a small (64 bytes) section of the drive that specifies the location, type, and length of each partition. MBR partitions keep this table at the very beginning of the drive. GPT partitions keep an additional backup at the end of the drive and add support for more features. When you overwrite an entire block device, the partition table is also wiped.

As another answer mentions, the partition layout itself is unimportant and contains no sensitive data. They contain essentially nothing other than the bare minimum of information required to split a disk up into multiple partitions. You can see exactly what is stored for both MBR and GPT tables:

Improve this answer
2

As far as data security is concerned, the partitions are almost meaningless. If you're trying to prevent forensics from reading your data, then it won't matter. If you've run a proper multi-pass shredder over the data, then the partitions will only matter if you named them something telling.

Addendum: I've obviously hit someone's sore spot by suggesting a multi-pass shredder, so I'll be more specific. A single pass of random data will prevent the drive itself from reading the overwritten data. Unless you're hiding data that's worth five figures or someone's life, you're good stopping there.

There are enlightened papers out there that state that a single pass of random values will make reading each byte slightly better than a coin-flip, but those papers are currently behind pay walls, so I cannot make a statement regarding the reliability of their methodology.

For older drives, the lack of precision of the mechanism can result in a single pass leaving traces that expensive forensics can still read. I suggest whacking longitudinally with a sledge hammer and baking at 350 degrees until brown.

Improve this answer
10
  • And to @robert's comment on proper multi-pass, a simple /dev/urandom is NOT a proper multi-pass and many like myself would argue /dev/urandom is not terribly secure for your stated needs as it will NOT lock on entropy depletion hence there is a chance a forensics look post wipe could still retrieve DATA from the partitions themselves. – linuxdev2013 Dec 27 '18 at 0:18
  • 6
    @linuxdev2013 That's a myth. A single zero or one pass is likely sufficient, and /dev/urandom is certainly good enough. "Entropy depletion" from /dev/urandom is a myth, the only real concern is lack of entropy on startup. And good luck wiping it with /dev/random unless you have a hardware random number generator. – AndrolGenhald Dec 27 '18 at 0:39
  • -1 because doing multi-pass is completely useless. You do not need to wipe multiple times. – forest Dec 27 '18 at 2:38
  • 1
    Your edit is incorrect as well. There are old, incorrect, retracted papers trying to identify data remanence. However, the reality is that a single overwrite on any modern, high-density drive is effectively equivalent to a 10000x overwrite. Think about it: Even wiped data on old audio tapes from watergate can't be recovered... – forest Dec 28 '18 at 2:53
  • 1
    @Motivated The drives are too old to be relevant. This was long before ATA Secure Erase was a thing. I think there are other answers here which already explain overwriting ancient MFM and RLL drives, though. – forest Dec 28 '18 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.