Firstly, I do not think my question is answered by SSD full disk encryption as I am not looking for a binary "is FDE secure" - nothing is perfectly secure; rather I am looking for possible solutions to the specific SSD/FDE encryption conundrum.
Theoretical attack model: My computer's root disk (all mounted partitions) is an SSD that has been encrypted using LUKS (let's assume V1) with a 6 character dictionary word as a password.
I'm aware that LUKS doesn't use passwords directly to (en/de)crypt data, rather it stores the actual key (or "Underlying Key") in a header located at or near the first (logical) sectors of the drive. It encrypts the Underlying Key with the password (salty hashed several times etc.); thus knowledge of the password becomes the only way (assuming no crypto breakthrough/software bugs/side-channel attacks) in which the Underlying Key and consequently the disk can be decrypted.
The weakness of this first password is supposedly protected by LUKS deploying password strengthening techniques (the aforementioned salted hash). I do not have a high degree of trust that these techniques will really hold off a well-funded and determined adversary. It is not completely implausible that well-funded specialists possess classified hardware that can perform some silly large number of [insert hash function here] ops/second. My example in the brackets is perhaps a shade far-fetched, but hopefully, it communicates my concern; I know that a password of a certain length derived from a true entropy source is impractical to brute force (even post-quantum) I'm not a cryptographer; I cannot mathematically demonstrate it; however I know it to be true as surely as I know that I cannot fly.
Going back to the attack scenario, I decide to upgrade my password to a stronger one. I fire off a crypsetup command (I'm on Arch), wipe the old keyslot, write the Underlying Key encrypted by a salted hash of the new password into said keyslot. So, password changed? Maybe. The drive reports that the logical sectors have been set to zero but the opaque drive controller and its antics means there is a complete disconnect between logical and physical sectors. To my knowledge there is no reliable way of confirming this using commodity hardware, without degrading the lifespan of the drive by, for example, repeatedly writing zeroes to the disk, like grenades, hoping that one of them will hit the target and actually zero out the Underlying Key ciphertext encrypted using the old password.
It is known that SSD and flash drives in general deploy a technique called wear-leveling to increase product lifespan. These products also use other 'optimisation techniques' that create unpredictability and opaqueness with respect to the state of the physical media: The device is not honest with the OS/BIOS about what physical sectors are actually being altered. In other words- if I tell an SSD drive to write zeroes to the first 10k sectors, it may not actually overwrite the first (by physical location) 10k.
Back to LUKS- this potentially creates a (well-known/acknowledged) risk that the Underlying Key, encrypted using an old password could be physically 'lurking' in the SSD media and readable assuming a sizeable budget and a serious data forensics specialist.
I'm aware that LUKS supports storing the header on a separate disk- perhaps a thumb drive that, given the tiny space requirement- could be cost-effective to physically destroy it with thermite plasma and a sander and replace upon every password change.
What specific methods, steps or tools can I use to mitigate the risk that the Underlying Key (encrypted by an old- let's assume weak or compromised- passphrase) that has been wiped/deleted/discarded/etc by LUKS is actually lurking on the flash storage because the drive's controller never actually overwrote the bits at a physical level?