And this is why you always encrypt the drive with software. All of these methods seem to put a lot of faith into the drive controller doing what it claim it does, which you can never be all that sure about. Even Microsoft-backed Bitlocker would help here.
I had a drawn out conversation with a friend about erasing NVME drives in a way that met compliance needs. The procedure they were given was to install Windows, with Bitlocker, twice with no effort to retain the key.
But that doesn't even overwrite the visible drive space; you can do a simple PoC to demonstrate that Windows won't get to all the mapped blocks. And that still hasn't gotten to the overprovisioned blocks and wear leveling issues that the article references.
You could use the BIOS or whatever CLI tool to tell the drive to chuck its encryption key, but are you sure that tool meets whatever compliance requirements you're beholden to? Are you sure the drive firmware does?
So they went with paying a company to shred the drives. All of them. It's disgustingly wasteful.
It's very common for both NVMe and SATA drives that they'll be locked/frozen during boot and thus will not honor a secure erase command until the drive has been power-cycled, which can usually be accomplished with the system-level sleep/wake cycle. I'm not sure what useful purpose this is meant to serve other than possibly making it hard for malware to instantly and irretrievably wipe your storage.
Gotta love breaking EFI changes. I don't know how many times my work laptop would do that and I couldn't boot anymore, only to remember some stressful time later that Linux would only boot with some of the settings flipped from their defaults. At least I never had to reinstall anything.
To maximize device performance when wiping a drive to use for something else, I use nvme format with --ses=1.
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice
best practice is always to encrypt with luks, and then just shred the header before selling.
blkdiscard is just a TRIM command, the data remains there.
A few years ago (2020?) I also learned that ssd firmware can be buggy when I bricked multiple really expensive enterprise ssd (samsung?)....by running trim. lol.
> So I connected it to the computer with the USB to NVME M.2 converter
> blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported
I've got a USB-to-NVME adapter that exposes the NVME namespaces as SCSI disks. `blkdiscard` did not work with these by default, however it worked fine after I changed the `provisioning_mode` attribute of the disk.
This can be done by identifying the SCSI device ID of the disk (lsscsi) and then changing it with:
`lsblk -D` will show which block devices support the discard operation; run it before and after changing provisioning_mode to see the difference.
This is absolutely not to be used as an alternative to a real 'sanitize' operation directly sent to the NVME controller. If you actually need to securely erase your data, and the drive dosesn't support the sanitize operation, then you should physically shred the drive and demand a refund from the retailed (goods as sold are not fit for purpose).
Overall, I've found dealing with nvme a frustrating experience. In theory it's nice to have NVME controller firmware be responsible for executing commands from the host (sanitize! change LBA size! underprovision by 30%!) but in practice, it's complete hit or miss whether controllers support a command or will reject it, or maybe they claim to support it but it doesn't work because the controller firmware is buggy shit.
I would like to have raw NAND devices and have the kernel be in charge of everything, but sadly that wouldn't work for Windows so we're stuck in proprietary firmware hell.
WTF is wrong with just copy/paste the same big unimportant file (like a movie) until you run out of space and then just delete them all? So much unnecessary hurdle with different utilities and commands that made my head spin. What do you think those utilities do in the background anyway if not filling the free space with junk, just like what a copy/paste does?
I never used ATA Security commands with NVME or SSDs, but I did use them with spinning rust ATA and SATA drives. I even had a BIOS module added into the firmware of the motherboard to manage ATA Security [0].
I have a few comments to make:
1)
Erase operation is in fact a succession of two commands: ATA Security Erase Pepare and ATA Security Erase Execute. No other command can be sent between these two, so any disk access by the OS after the first command would cause the second to fail.
2)
ATA Security commands are usually blocked ("frozen") after boot if the drive has no password or was password-unlocked. That means the drive will not accept commands to set/change password or erase until power-cycled. That is a full power cut, not just a reset-drive command.
This feature prevents a virus from passwording or erasing your drive. Yes, it can still crypto-lock or erase your drive via ordinary disk writes, but that takes hours for the whole drive, while ATA Security Erase or setting a password takes a millisecond or so.
The ATA Security Freeze command is sent to the drive either by the BIOS/UEFI (my BIOS didn't do this, but probably all laptops have it as part of their BIOS/UEFI Security features), by a BIOS module (my desktop BIOS didn't have it), by the operating system as part of drive encryption features, or by an antivirus. Also, the drive firmware may have a timer to automatically freeze ATA Security commands after a timeout if it doesn't receive the explicit command from the host.
Power cycling by putting the system to sleep and then wake up will NOT work, because if the drive is locked with a password, it needs to be unlocked BEFORE the firmware/ACPI gives control back to the operating system. Otherwise, the OS would no longer be able to access the disk after wake up. So, the BIOS/UEFI/ACPI, if it supports ATA Security at all, will automatically freeze ATA Security commands again during wake-up, just as it did during cold boot.
In conclusion, the dive must be physically unplugged from power and then hot-plugged. Or start the computer without it, and hot-plug it after boot.
3)
Many (most?) USB adapters don't support ATA commands at all. They'll just emulate a USB mass storage with no direct access to the drive. What you need is an adapter that supports UAS (USB Attached SCSI). And even then, I'm not sure ATA Security commands have a SCSI equivalent so they can be translated.
The best option here is to hot-plug into a real SATA port on the motherboard or PCI/PCIe controller. NOT via USB.
15 comments
[ 2.6 ms ] story [ 40.5 ms ] threadBut that doesn't even overwrite the visible drive space; you can do a simple PoC to demonstrate that Windows won't get to all the mapped blocks. And that still hasn't gotten to the overprovisioned blocks and wear leveling issues that the article references.
You could use the BIOS or whatever CLI tool to tell the drive to chuck its encryption key, but are you sure that tool meets whatever compliance requirements you're beholden to? Are you sure the drive firmware does?
So they went with paying a company to shred the drives. All of them. It's disgustingly wasteful.
If you insist on erasing the data, overwrite the entire contents of the drive twice with random data.
Doing it twice will blow away any cached as well (probably).
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice
Every organization with good security hygiene requires physical destruction of SSDs. Full stop, end of negotiation, into the shredder it goes.
Not that it matters much, with the prices of SSDs skyrocketing people are moving back to mechanical disks.
blkdiscard is just a TRIM command, the data remains there.
A few years ago (2020?) I also learned that ssd firmware can be buggy when I bricked multiple really expensive enterprise ssd (samsung?)....by running trim. lol.
> blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported
I've got a USB-to-NVME adapter that exposes the NVME namespaces as SCSI disks. `blkdiscard` did not work with these by default, however it worked fine after I changed the `provisioning_mode` attribute of the disk.
This can be done by identifying the SCSI device ID of the disk (lsscsi) and then changing it with:
`lsblk -D` will show which block devices support the discard operation; run it before and after changing provisioning_mode to see the difference.This is absolutely not to be used as an alternative to a real 'sanitize' operation directly sent to the NVME controller. If you actually need to securely erase your data, and the drive dosesn't support the sanitize operation, then you should physically shred the drive and demand a refund from the retailed (goods as sold are not fit for purpose).
Overall, I've found dealing with nvme a frustrating experience. In theory it's nice to have NVME controller firmware be responsible for executing commands from the host (sanitize! change LBA size! underprovision by 30%!) but in practice, it's complete hit or miss whether controllers support a command or will reject it, or maybe they claim to support it but it doesn't work because the controller firmware is buggy shit.
I would like to have raw NAND devices and have the kernel be in charge of everything, but sadly that wouldn't work for Windows so we're stuck in proprietary firmware hell.
I have a few comments to make:
1)
Erase operation is in fact a succession of two commands: ATA Security Erase Pepare and ATA Security Erase Execute. No other command can be sent between these two, so any disk access by the OS after the first command would cause the second to fail.
2)
ATA Security commands are usually blocked ("frozen") after boot if the drive has no password or was password-unlocked. That means the drive will not accept commands to set/change password or erase until power-cycled. That is a full power cut, not just a reset-drive command.
This feature prevents a virus from passwording or erasing your drive. Yes, it can still crypto-lock or erase your drive via ordinary disk writes, but that takes hours for the whole drive, while ATA Security Erase or setting a password takes a millisecond or so.
The ATA Security Freeze command is sent to the drive either by the BIOS/UEFI (my BIOS didn't do this, but probably all laptops have it as part of their BIOS/UEFI Security features), by a BIOS module (my desktop BIOS didn't have it), by the operating system as part of drive encryption features, or by an antivirus. Also, the drive firmware may have a timer to automatically freeze ATA Security commands after a timeout if it doesn't receive the explicit command from the host.
Power cycling by putting the system to sleep and then wake up will NOT work, because if the drive is locked with a password, it needs to be unlocked BEFORE the firmware/ACPI gives control back to the operating system. Otherwise, the OS would no longer be able to access the disk after wake up. So, the BIOS/UEFI/ACPI, if it supports ATA Security at all, will automatically freeze ATA Security commands again during wake-up, just as it did during cold boot.
In conclusion, the dive must be physically unplugged from power and then hot-plugged. Or start the computer without it, and hot-plug it after boot.
3)
Many (most?) USB adapters don't support ATA commands at all. They'll just emulate a USB mass storage with no direct access to the drive. What you need is an adapter that supports UAS (USB Attached SCSI). And even then, I'm not sure ATA Security commands have a SCSI equivalent so they can be translated.
The best option here is to hot-plug into a real SATA port on the motherboard or PCI/PCIe controller. NOT via USB.
[0] https://www.fitzenreiter.de/ata/ata_eng.htm