Using aes-generic, kind-of regression in 7.0

Using aes-generic, kind-of regression in 7.0

[Milan Broz]

Hi Eric,

we see failures in cryptsetup testsuite, caused by commit
a2484474272ef98d9580d8c610b0f7c6ed2f146c "crypto: aes - Replace aes-generic with wrapper around lib"

TBH I am not sure this is a regression, as the internal naming (like aes-generic) was not supposed
to be used in userspace. Unfortunately, it happened by (perhaps my) mistake with introducing "capi" syntax in dm-crypt.

For example this command
   dmsetup create test --table "0 8 crypt capi:xts(ecb(aes-generic))-plain64 7c0dc5dfd0c9191381d92e6ebb3b29e7f0dba53b0de132ae23f5726727173540 0 /dev/sdb 0"

now fails. Replacing "aes-generic" with "aes-lib" obviously works.

Cryptsetup tests use aes-generic to simulate some of these "capi" fu***ups.
(LUKS now explicitly disables using that dash driver syntax.)

I can fix cryptsetup testsuite, but I am not sure if anyone actually use this (specifically to avoid using aes-ni or some accelerated crypto drivers).

I am not sure what to do with that... *-generic name could be used as some defaults.

Is it worth to introduce some compat mapping, or just document this was just not a supported thing?

Thanks,
Milan

Re: Using aes-generic, kind-of regression in 7.0

[Eric Biggers]

On Thu, Feb 19, 2026 at 07:49:18PM +0100, Milan Broz wrote:
> Hi Eric,
> 
> we see failures in cryptsetup testsuite, caused by commit
> a2484474272ef98d9580d8c610b0f7c6ed2f146c "crypto: aes - Replace aes-generic with wrapper around lib"
> 
> TBH I am not sure this is a regression, as the internal naming (like aes-generic) was not supposed
> to be used in userspace. Unfortunately, it happened by (perhaps my) mistake with introducing "capi" syntax in dm-crypt.
> 
> For example this command
>   dmsetup create test --table "0 8 crypt capi:xts(ecb(aes-generic))-plain64 7c0dc5dfd0c9191381d92e6ebb3b29e7f0dba53b0de132ae23f5726727173540 0 /dev/sdb 0"
> 
> now fails. Replacing "aes-generic" with "aes-lib" obviously works.
> 
> Cryptsetup tests use aes-generic to simulate some of these "capi" fu***ups.
> (LUKS now explicitly disables using that dash driver syntax.)
> 
> I can fix cryptsetup testsuite, but I am not sure if anyone actually use this (specifically to avoid using aes-ni or some accelerated crypto drivers).
> 
> I am not sure what to do with that... *-generic name could be used as some defaults.
> 
> Is it worth to introduce some compat mapping, or just document this was just not a supported thing?

The crypto "driver names" have effectively always been an implementation
detail and not useful to specify directly.  They have changed before,
e.g. in v4.10 "xts(aes-generic)" changed to "xts(ecb(aes-generic))".  In
practice, what users actually want is for the kernel to select the
"best" implementation automatically, which is done by simply specifying
the stable name "xts(aes)" rather than a specific driver name.

The change of the CPU-based driver names to *-lib, which started for
other algorithms in v6.16, reflect a simplification to not expose
individual CPU-based implementations in the API.  Instead the
traditional crypto API is now just implemented on top of lib/crypto/,
which uses the "best" implementation automatically and by default.

This is the first issue report since that started.  So clearly this
simplified approach has generally been working fine, as expected.

In this particular case, the user is just a test script.  Also, it seems
it doesn't actually care that it gets the generic code specifically, but
rather it just uses a "driver name" rather than a "name" to verify that
dm-crypt's "capi:" syntax accepts "driver names" and not just "names".

So while we could introduce an "aes-generic" alias if absolutely needed,
I don't think this test script is enough to motivate that.  For now the
test script should just be updated to use the new driver name, or fall
back to the old driver name if the new one isn't supported.  And yes, I
recommend updating the cryptsetup documentation to clarify that
specifying crypto "driver names" isn't really supported.  Actually, if
that is done, maybe the test case isn't even needed at all anymore.

As for disabling AES-NI, no one actually wants to do that in practice.
But even if they did, it can still be easily done using the kernel
command-line option "clearcpuid=aes".  That's a more comprehensive
solution to disable the use of a particular CPU feature in the kernel.

- Eric

Re: Using aes-generic, kind-of regression in 7.0

[Milan Broz]

On 2/19/26 9:11 PM, Eric Biggers wrote:
> On Thu, Feb 19, 2026 at 07:49:18PM +0100, Milan Broz wrote:
>> Hi Eric,
>>
>> we see failures in cryptsetup testsuite, caused by commit
>> a2484474272ef98d9580d8c610b0f7c6ed2f146c "crypto: aes - Replace aes-generic with wrapper around lib"
>>
>> TBH I am not sure this is a regression, as the internal naming (like aes-generic) was not supposed
>> to be used in userspace. Unfortunately, it happened by (perhaps my) mistake with introducing "capi" syntax in dm-crypt.
>>
>> For example this command
>>    dmsetup create test --table "0 8 crypt capi:xts(ecb(aes-generic))-plain64 7c0dc5dfd0c9191381d92e6ebb3b29e7f0dba53b0de132ae23f5726727173540 0 /dev/sdb 0"
>>
>> now fails. Replacing "aes-generic" with "aes-lib" obviously works.
>>
>> Cryptsetup tests use aes-generic to simulate some of these "capi" fu***ups.
>> (LUKS now explicitly disables using that dash driver syntax.)
>>
>> I can fix cryptsetup testsuite, but I am not sure if anyone actually use this (specifically to avoid using aes-ni or some accelerated crypto drivers).
>>
>> I am not sure what to do with that... *-generic name could be used as some defaults.
>>
>> Is it worth to introduce some compat mapping, or just document this was just not a supported thing?
> 
> The crypto "driver names" have effectively always been an implementation
> detail and not useful to specify directly.  They have changed before,
> e.g. in v4.10 "xts(aes-generic)" changed to "xts(ecb(aes-generic))".  In
> practice, what users actually want is for the kernel to select the
> "best" implementation automatically, which is done by simply specifying
> the stable name "xts(aes)" rather than a specific driver name.

Sure, just dmcrypt cannot use "capi:xts(ecb(aes))-plain64" either.
For test using "capi:xts(aes)-plain64" should be ok, I will change it.

> The change of the CPU-based driver names to *-lib, which started for
> other algorithms in v6.16, reflect a simplification to not expose
> individual CPU-based implementations in the API.  Instead the
> traditional crypto API is now just implemented on top of lib/crypto/,
> which uses the "best" implementation automatically and by default.
> 
> This is the first issue report since that started.  So clearly this
> simplified approach has generally been working fine, as expected.
> 
> In this particular case, the user is just a test script.  Also, it seems
> it doesn't actually care that it gets the generic code specifically, but
> rather it just uses a "driver name" rather than a "name" to verify that
> dm-crypt's "capi:" syntax accepts "driver names" and not just "names".
> 
> So while we could introduce an "aes-generic" alias if absolutely needed,
> I don't think this test script is enough to motivate that.  For now the
> test script should just be updated to use the new driver name, or fall
> back to the old driver name if the new one isn't supported.  And yes, I
> recommend updating the cryptsetup documentation to clarify that
> specifying crypto "driver names" isn't really supported.  Actually, if
> that is done, maybe the test case isn't even needed at all anymore.

I do not think alias is needed until someone reports this for a real use case.
As I said, we do not support this is userspace libcryptsetup.

But as seen above, dmsetup allowed it if talking directly to dm-crypt.

Thanks,
Milan