Re: Cryptsetup and hardware accelerated AES-XTS

On 7/20/24 2:15 PM, Maxim Fomin wrote:
> Recently linux kernel got[1] faster AES-XTS on modern x86_64 CPUs
> thanks to VAES and AVX-10/512. I decided to dig deeper into this
> issue and found the article[2] from 2020 stating that dm-crypt can be
> configured to use faster (synchronous and hardware accelerated)
> algorithms with 'capi:' prefix. Can cryptsetup be configured to ask
> dm-crypt to use hardware accelerated algorithms?

Hi,

TL;DR - you cannot use "capi" driver specification with cryptsetup.

As Eric said in other reply, it is up to the kernel to set priority
which driver is used in kernel. You can always blacklist some modules.


For the archive, some context below.

The "capi" format support in dm-crypt was introduced due to the support
for authenticated encryption where original cipher dm-crypt format cannot
be used.
It was actually my mistake that we allowed specification of specific
*driver* in dm-crypt mapping table - this is really not job for dm-crypt.

Currently, while dm-crypt allows that driver specification, cryptsetup
will reject it as it is possible security problem.
Quoting from the cryptsetup 2.7.0 release notes
https://www.kernel.org/pub/linux/utils/cryptsetup/v2.7/v2.7.0-ReleaseNotes


* Disallow the use of internal kernel crypto driver names in "capi"
   specification.

   The common way to specify cipher mode in cryptsetup is to use
   cipher-mode-iv notation (like aes-xts-plain64).
   With the introduction of authenticated ciphers, we also allow
   "capi:<spec>" notation that is directly used by dm-crypt
   (e.g., capi:xts(aes)-plain64).

   CAPI specification was never intended to be used directly in the LUKS
   header; unfortunately, the code allowed it until now.
   Devices with CAPI specification in metadata can no longer be activated;
   header repair is required.

   CAPI specification could allow attackers to change the cipher
   specification to enforce loading some specific kernel crypto driver
   (for example, load driver with known side-channel issues).
   This can be problematic, specifically in a cloud environment
   (modifying LUKS2 metadata in container image).

   Thanks to Jan Wichelmann, Luca Wilke, and Thomas Eisenbarth from
   University of Luebeck for noticing the problems with this code.

Thanks,
Milan