> I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key?
Again, the reason why it's different is the security model for memory is different from the filesystem. This is exactly what I was getting at: the fixed key. Encrypted swap volumes typically are set up to use ephemeral keys that are "forgotten" when you power down. The idea is that you only have access to that memory while the computer is running. When you boot up again, whatever data is in the swap partition is just noise. As mentioned in the link I provided (https://help.ubuntu.com/community/EnableHibernateWithEncrypt...), the current solution is to switch to using a fixed key, much as you described. That fundamentally changes the security model, and not in a subtle way.
I think there's a solution that more closely approximates the security model, with only a minor compromise: when you boot up, you generate an ephemeral key in the secure enclave, and use that to encrypt your swap. When you hibernate, the secure enclave encrypts all the metadata (including the ephemeral key) into a sealed state that is stored on disk with the swap information. When you restore, the sealed data is read back into the secure enclave (and erased) and it can then decrypt swap as needed. This still means the hibernated memory state is fully recoverable by whomever is able to authenticate with the enclave, but that's what everyone wants. On the upside, if you shut down the machine (rather than hibernate), the ephemeral key is lost, so there's no way anyone can recover what's on your swap, even if they have access to whatever fixed key(s) you have used for your LVM volumes.
If you're really paranoid, you could even generate a new ephemeral key on restore and reencrypt the entire swap volume with the new ephemeral key, though I'd question what realistic threat model that would really address.