I got a replacement for my Samsung MZVLW256HEHP-000L7 NVMe 256GB M.2 PCI Express X4 SSD, known also simply as Samsung PM961. It is an OEM part. After replacing it with the new one, Samsung 980 1TB, I put the old one on sale. This was my daily driver, so I did not want any meaningful data to be recoverable from it. So I connected it to the computer with the USB to NVME M.2 converter (AXAGON EEM2-SG2), which by the way I can now recommend (no affiliate link, sorry) and started the old, magnetic HDD type of secure data erase, using shred utility:

Caution: the following command(s) will IRREVERSIBLY destroy your data. Proceed only when you understand the implications!

shred -vfz /dev/sdX

But stop! The shred or similar utility like dd is not a best way to securely erase SSD! The thread recommends blkdiscard utility:

blkdiscard -s /dev/sdX

This command on the other hand should not decrease the lifespan of the SSD so drastically the shred does, but looks like data are still quite recoverable after (depending on the threat model). It did not work for me however:

blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported

Looking around the Internet it then suddenly became apparent to me that there are at least a dozen ways to "securely and properly erase an NVME SSD".

Starting with this answer talking about the way ATA SSD drives can be securely erased quickly just by changing the encryption password using the hdparm utility:

hdparm --user-master u --security-set-pass hunter1 /dev/sdX
hdparm --user-master u --security-erase hunter1 /dev/sdX

This failed, but I expected it, as my drive was NVME SSD, not SATA SSD. The output for the record:

Issuing SECURITY_SET_PASS command, password="hunter1", user=user, mode=high
SECURITY_SET_PASS: Inappropriate ioctl for device

However, this got me on the track, as I had no idea about this whole "encryption password" rabbit hole. Searching further led me to another answer explaining the same process, but for NVME drives using the nvme-cli utility. Exactly what I needed. A quick glance at the options:

sudo pacman install nvme-cli
man nvme format
man nvme sanitize

This is probably what I needed - securely erase the drive, resetting the drive's cryptographic password during the process (-s2):

nvme list
nvme format -s2 /dev/nvme0n1

Running NVME sanitize would probably be even better option as it appears to also clear any caches, not just the data in the namespace, but I would definitely need more time studying both. Also, I could not even run in properly, getting complains about bad sanitize argument. Consider doing your own research.

The nvme tool however failed right on the step 1 listing the devices using nvme list. The reason is that the USB to NVME M.2 converter probably does not implement all the required commands, as hinted in this comment.

So I put the old NVME back into the laptop and booted a live Linux image from the USB. Now, the NVME connected over native PCIe lanes without any USB converted in the way, the nvme list command properly recognized the drive, outputting detailed information about Node, Generic, SN, Model, Namespace, Usage, Format and FW Revision of the PM961 drive.

The Debian live did not complain, but the Arch live, probably due to a newer version of nvme-cli complained a little bit before outputting the contents of the nvme list, but proceeded as well:

nvme0: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2)

Trying the nvme format command again failed spectacularly in Debian live:

NVMe status: INVALID_OPCODE: The associated command opcode field in not valid(0x2001)

In Arch live, the error was, as expected, even a little bit more verbose:

nvme0: Format NVM(0x80), Invalid Command Opcode (sct 0x0 / sc 0x1)
NVMe status: Invalid Command Opcode: A reserved coded value or an unsupported value in the command opcode field(0x2001)

Ouch. It is noted here and here that it is a known bug for a Samsung PM951 and PM961 and s simple suspend should resolve the issue. I was happy a for a brief moment. Sadly, somehow this has did not work for me, yet again. There was no change in the behavior From here on, the ride was a steep downhill.

Other suggestions in the above two GitHub threads were to use a Lenovo EFI application which is a bootable image that works on ThinkPads (I still rock the trusty T470 at the time of writing) and is meant to erase a cryptographic key on the SSD. I was not able to boot this piece of software by any means, not in UEFI mode, nor in Legacy BIOS mode, nor in any other combination that came to my mind (there is note about it being supported only in UEFI only or UEFI First boot mode).

Another option is to use Lenovo NVME Firmware Utility which is for Windows (but I can dual-boot from mSATA PCIex1 Transcend 430S 512GB internal SSD drive), but following these instructions it appears the updater utility could even be run on Arch or other Linux distribution (again, not tested yet). Trying this on Windows, it correctly identified both Transcend 430S and Samsung PM961 to be present, but it did not offer a Firmware update for either. So no luck here.

As a last resort, I tried the easier firmware upgrade option, a fwupdmgr which is part of the fwupd package but, as I expected, it did not pick the Samsung PM961 SSD for an update. It did however updated my Intel Management Engine and also System Firmware, which I assume was BIOS, as the next reboot updated the BIOS with a new version containing breaking changes to EFI (that were mentioned during the install process), which in turn required me to reinstall GRUB from live Arch. Living on the edge.

This is the end. In the beginning I thought it would be a simple device formatting and here I am in the middle of the night with the drive that is still not prepared to be handed to some stranger. Will probably go for the shred and hope for the best. Wish me luck!

Update 19th April 2024#

I have received an email from Tim Small [email protected] adding a few bits to this topic. They also agreed for me to post this update here along with author's name and email, which is always nice, so I did. Here's a verbatim source of the contribution:

Hi Peter,

Thanks for your blog post. I hit the same issue trying to erase a PM951.

I found an article on the "knowledge base" of Blanco (a commercial disk erasing software). It says:

"This issue concerns Samsung PM951 NVMe (256/512gb) drives and Blancco Drive Eraser 6.x version(s)." ... "erasure fails with the following message: "FORMAT UNIT command failed. Device is NVMe, see manual for more information". In this case the drive does not respond to the 'format unit' nvme firmware erasure command properly.

The fix for this issue is to force the Freeze Lock Removal process in Blancco Drive Eraser, by using a customized startup option."

"Add flr=forced to the end of the command."

Since I had a Dell Optiplex 7070 at hand (and I was under time pressure), I opted to use the "Data wipe" option of that machine's firmware instead, since I'd guessed that it would include whatever secret commands were necessary to carry out a security erase on these drives.

Cheers,

Tim.

If someone finds this bit actually works, please let me know, as I do not have the drive anymore, to test this. Enjoy!

Links#