How do we know that the firmware is actually erasing the block containing the encryption key?
Maybe it just leaves the block/key intact and alters the NVRAM key-address to point to another block or key-location, resulting in a history of every key used on the storage device.
In which case no matter how many times the device was secure-erased a well-equipped adversary could have ways to extract previous keys, either whilst the device is 'online' via undocumented commands, or whilst 'offline' with dedicated equipment.
The same 'destroy-the-key-not-the-data' procedure can be used from the user-controlled software level - Linux with LUKS/dm_crypt uses the same approach via the LUKS header, which can also be 'detached' - only stored on a different (possibly removable) device entirely.
As a bonus it is secure even against malicious (snooping) drive firmware since only encrypted data is seen by the I/O controller and storage device.
One might turn that argument around: with OS-level encryption, you're trusting your OS and your CPU (even if it has a TPM) to not include NSA backdoors that will make it divulge its key, or use a different key for encrypting the drive than the one it says it's using.
With drive-level encryption, the drive effectively acts as its own TPM: the drive's encryption keys never leave the drive (and there's no API to ask for them), so—excepting drives that allow their firmware to be upgraded—there's no possibility of some other untrusted component of your system pulling off a record of the drive keys for later offline recovery.
The best procedure is to combine the two, of course. There's no added cost to disk-firmware-level encryption, since each disk-block is going through a rather complex transformation anyway to protect it from the vagaries of flash array storage. And CPU time for doing OS-level encryption is cheap. Turning both on—and telling the OS to secure-erase its key before telling the disk to secure-wipe—protects you from both attackers.
---
If, for some reason, you only have one or the other available to you, though, I'd honestly prefer the disk-firmware-level encryption, with a foreign-made drive. (This is going to be a bit of a tangent.)
Both CPUs and disks can do encryption. Both CPUs and disks can keep the key locked inside themselves, basically acting as TPMs. And both CPUs and disks can have been suborned at the design or manufacturing stage by a state actor.
My main choices of CPU (Intel, AMD, ARM), regardless of where they end up being manufactured, were all designed by either US or British firms—that is, firms within the jurisdiction of the Five Eyes SIGINT-sharing agreement. I have many choices of disks, though, and many of those options are both designed and manufactured outside of that jurisdiction, in e.g. China.
Now, while I might not trust foreign state-level SIGINT any more than domestic, the incentives are different. Even if Chinese drives have suborned firmware, China has no reason to care what's on my drives—because I'm not a Chinese citizen—or any way to force me to hand the drive over—because I'm not physically in China—and no way to make me be in China, because Canada (where I live) has no extradition treaty with China.
Meanwhile, if I relied on a US-designed/manufactured drive, the NSA would care what's on my drives (because Canada's NSA-equivalent, the CSE, asks them to)—and, because Canada and the US do have an extradition treaty, I could get extradited to the US for a US law the NSA says I broke—and I then would be forced to hand the drive over, where the backdoored keys could be extracted and used to recover the drive's contents.
All these arguments are reversed, of course, if you deal in state secrets, or industrial trade-secrets, that foreign state-actors would actively target you for. The military has every reason to only want domestic CPUs and domestic drives. But I'm not a spy, or a diplomat, or a military officer, or an electrical-utility tycoon; I'm just a private citizen. The only country that cares about me, for better or worse, is my own (and, y'know, those other ones that they attend SIGINT club with on Friday nights.)
How do we know that the firmware is actually erasing the block containing the encryption key?
Maybe it just leaves the block/key intact and alters the NVRAM key-address to point to another block or key-location, resulting in a history of every key used on the storage device.
In which case no matter how many times the device was secure-erased a well-equipped adversary could have ways to extract previous keys, either whilst the device is 'online' via undocumented commands, or whilst 'offline' with dedicated equipment.
The same 'destroy-the-key-not-the-data' procedure can be used from the user-controlled software level - Linux with LUKS/dm_crypt uses the same approach via the LUKS header, which can also be 'detached' - only stored on a different (possibly removable) device entirely.
As a bonus it is secure even against malicious (snooping) drive firmware since only encrypted data is seen by the I/O controller and storage device.