By default, yes. But it is possible to enable Bitlocker to use a SED directly.

hdparm secure erase runs on the drive controller though, the "hdparm" utility just initiates it? So it's not depending on whether the OS can or cannot see specific sectors. At least that's my understanding.

There is nothing "wrong" with passwords, but they have trade-offs like most approaches. The actual LUKS key is usually wrapped in a password protected record(s) commonly on the storage media by default. That method is usually weaker than the key itself.

Note 10000 GPUs can brute force passwords rather quickly (a pre-sharded search space is fast), and key exfiltration for targeted individuals/firms still happens.

Options like modern TPM include anti-brute force features, but has other attack surfaces. Everyone has their own risk profile, and it is safer to assume if people want in... they will get in sooner or later. ymmv =3

I've lost faith that Linux distros will ever fix the problem where some PCR changes and the TPM refuses to unseal the key... the user is left with a recovery passphrase prompt & no way to verify whether they have been attacked by the 'evil maid', or whether it was just because of a kernel or kernel command line or initrd or initrd module change, etc.

It is common to remote mount JBOD over initrd drop-bear ssh using sector level strip signature checking, predicted s.m.a.r.t power-cycle-count/hours/serial, proc structure, and an ephemeral key. SElinux is also quite robust in access permission handling.

TPM collocates a physical key on the same host, incurs its own set of trade-offs with failures or physical access in dormancy, and requires trusting yet another vendor supply chain. There are always better options, but since the Intel Management Engine can access TPM... such solutions incur new problems. Privilege escalation through TPM Sniffing is also rather trivial these days.

Have a great day. =3