scrub(1) doesn't even mention SSD devices

[garlick]

Problem: the scrub man page provides no guidance on what you should do to securely erase an SSD/NVMe drive.

[garlick]

Excerpts from email discussion with Stephen (thanks!)

Stephen:

what is the best way to use scrub to scrub an entire SSD?

Garlick:

There is no explicit support for SSDs, and features like wear leveling
would give me pause. Obviously the pattern sequences designed to wipe
out residual magnetic signal on a platter are not going to be that
helpful on silicon.

If this is for a compliance requirement, then you'd want to get into
the details of the requirement. I haven't researched any of the
standards that scrub supports to see what they say about SSDs.

If you have a lot of the same manufacturer SSDs, then I'd check with
the manufacturer to see if they have some software that can do a
secure erase specific to their implementation.

If its a personal one-off, and you're not too paranoid, then a full
device wipe with a single random pass would probably satisfy me.

If you were proposing to scrub a partition or file within an SSD, the
wear leveling would really concern me, since you might be writing on
completely new space, not over your old space.

Stephen:

There is documentation out there that TRIM or fstrim is really not enough as a deletion method, i.e. not secure. And I wonder what an equivalent of scrub could be to secure delete/wipe selectively on an SSD.
Looks like this hasn't been invented yet and/or that the technology does not allow for single file wiping or scrubbing.
As far as full device wiping, rhe consensus seems to be to use Secure Erase in hdparm as referred here: https://www.thomas-krenn.com/en/wiki/Perform_a_SSD_Secure_Erase

Garlick:

There is yet another mechanism to do the equivalent of secure erase on
an NVMe device: https://superuser.com/questions/1530363/how-to-securely-erase-an-nvme-ssd

[stef204]

More information can be found here:

https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing

and

https://wiki.archlinux.org/title/Solid_state_drive

[stef204]

Tip: If your SSD is locked (this can be due to having a BIOS password which which will put the SSD in the lockedstate):

1. boot your computer
2. put the computer in the sleep (or suspend) state.
   (On many laptops, one can just close the lid; and wait for box to go to sleep.)
3. wake the computer (e.g. open the lid.)

At that point, the SSD should show not 'locked` and one can apply the secure erase steps referenced above.

More on this page: https://tinyapps.org/docs/wipe_drives_hdparm.html

[pete4abw]

Or, as a matter of best practice, for the paranoid, just encrypt the SSD volumes while setting up. Then, when it comes time to remove, wipe the partition info for the drive and all its physical or logical volumes. LUKS type encrypted volumes cannot be recovered without the header.

https://security.stackexchange.com/questions/151585/best-current-methods-for-preventing-data-leakage-from-ssd?rq=1

$ cryptsetup status /dev/mapper/volname
/dev/mapper/volname is active and is in use.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  key location: dm-crypt
  device:  /dev/loop0
  loop:    /home/peter/volname
  sector size:  512
  offset:  4096 sectors
  size:    1019904 sectors
  mode:    read/write

header size will be sectors * offset or in this case 512 * 4096 = 2,097,192
Then scrub the first 2,097,192 bytes in this case from the unmounted device.
$ scrub -s 2097192 /dev/volname
Much less wear and tear on the device.
or
$ cryptsetup erase devicename
From the manpage

  erase <device>
  luksErase <device>

         Erase all keyslots and make the LUKS container permanently inaccessible.  You do not need to provide any password for this operation.

         WARNING: This operation is irreversible.