No. LUKS or dm-crypt are independent of hardware encryption. LVM is just volume management and is orthogonal to encryption.

From the attack model this is looking at no; cold storage LUKS encryption is safe.

The downside of having encryption done on the CPU is that it has a max throughput and latency burden (even with AES acceleration) which isn't a problem for SATA devices (both HDD & SSD) but it is with new high-end NVMe drives that can see througput in excess of 1GB/s.

On the other hand, LUKS still has it's own attack methods when a volume is opened (cold->hot). If the keyfile/password is stored on a seperate drive or entered manually, the interface (USB keyboard, SATA connection, motherboard chipset, etc) could be exploited to retrieve the key in cleartext. If the key is stored or tied to the machines TPM, then it's up in the air as to wheter Intel/AMD + the motherboard's manufacture didn't leave a flaw somewhere. i.e How much more secure is the mobo/CPU TPM than the OPAL/ATA based encryption found on these drives?

It affects the hardware encryption of the drives themselves, the issue is independent of the OS.

The question is whether or not other full-disk encryption implementations defer to on=device encryption hardware if present. As the paper notes, with the advent of embedded AES instructions in Intel processors, there is little or no performance advantage to doing so, and given the near-certainty that a crypto implementation done by a company or group that isn't a crypto-specialist is going to be flawed, it will likely compromise security to do so.

There may not be an IO performance disadvantage to using Intel AES-NI for dmcrypt, versus in-hardware (in the drive). But there is a CPU performance impact when using it. I see ~22% x4 thread (~88% CPU out of 400%) for kcryptd processes when fully utilizing reads or writes for a single laptop hard drives at ~140MB/s with an Intel Pentium N3700 in an Intel NUC. That's obviously not a very substantial CPU. But it is nevertheless a fairly substantial CPU hit. The spare CPU cycles are available so it doesn't have an actual impact on this system.

Anyway, neither kernel fscrypt, nor dmcrypt have any dependency on drive embedded crypto. They do use AES-NI or equivalent, if available and if that support is compiled into the kernel.

Detail output from top while doing a scrub on a LUKS encrypted system. (Expires in 7 days.) https://paste.fedoraproject.org/paste/IvXs0f-N2~qN-k32Z2Y~yA...

> The question is whether or not other full-disk encryption implementations defer to on=device encryption hardware if present.

dm-crypt (of which LUKS is a part) certainly does not do that.