Hello,
I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
the partition cannot be opened and I have the following errors when
booting:
device-mapper: table: 253:0: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
I found that this commit is responsible for the regression (reverting it
solves the problem):
> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> Author: Herbert Xu <[email protected]>
> Date: Tue Nov 22 20:08:19 2016 +0800
>
> crypto: xts - Convert to skcipher
Some precision: I am using the vanilla kernel source for 4.10. The aes,
xts and dm-crypt modules are directly compiled in the kernel and not as
modules. I also had the same problem with kernel 4.10-rc*.
Is it a known issue? I found 1 related email with no answer on the
dm-crypt mailing. If this is a regression, I can start digging, although
any guidance would be greatly appreciated.
Thank you in advance,
Best regards,
--
Nicolas Porcel
On 02/22/2017 12:17 AM, Nicolas Porcel wrote:
> Hello,
>
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
>
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
>
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
>
>> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
>> Author: Herbert Xu <[email protected]>
>> Date: Tue Nov 22 20:08:19 2016 +0800
>>
>> crypto: xts - Convert to skcipher
>
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.
Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much earlier:-)
I guess either there is a bug in some specific dependency missing
dependency in kernel config. Could you send your kernel .config that fails?
Do you have ECB mode compiled-in as well?
(See commit description, shouldn't XTS now select ECB as well? This seems to me
like a bug...)
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.
What mail on dmcrypt list? I do not see any recent mail.
Milan
What XTS implementations do you have available on /proc/crypto after the
error?
Some drivers that allocate fallback implementations using the older API
started to fail after the generic templates were converted to skcipher.
On Wed, Feb 22, 2017 at 12:17:17AM +0100, Nicolas Porcel wrote:
> Hello,
>
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
>
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
>
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
>
> > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> > Author: Herbert Xu <[email protected]>
> > Date: Tue Nov 22 20:08:19 2016 +0800
> >
> > crypto: xts - Convert to skcipher
>
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.
>
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.
>
> Thank you in advance,
>
> Best regards,
>
> --
> Nicolas Porcel
--
Regards,
Marcelo
On Wed, Feb 22, 2017 at 12:31:30PM +0100, Milan Broz wrote:
> Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much earlier:-)
I was surprised that it was still broken in the mainline release. All
the other regressions I had have been fixed. Also, I guess LUKS with
aes-xts is quite standard.
> I guess either there is a bug in some specific dependency missing
> dependency in kernel config. Could you send your kernel .config that fails?
>
> Do you have ECB mode compiled-in as well?
Nice guess. I had ECB enabled as a module, and I don't think it was
present in the initramfs. Compiling it in the kernel solves the problem.
Thanks for the clue!
I now have the xts(ecb(aes-generic)) driver appearing in /proc/crypto.
I had no xts driver before.
I don't think it's necessary now to copy my kernel config. Also, it's
quite minimalist: make defconfig with a few drivers I need, mostly compiled
in the kernel.
> (See commit description, shouldn't XTS now select ECB as well? This seems to me
> like a bug...)
I was actually confused by the message, I thought it would fallback to
the old implementation. I guess the XTS module should select ECB if
that's not the case. Should I submit a patch for that? Or maybe it would
be easier if a maintainer directly makes the change?
> What mail on dmcrypt list? I do not see any recent mail.
It was a mail from 2012, I should be more careful with search engines...
--
Nicolas Porcel
Since the
commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
crypto: xts - Convert to skcipher
the XTS mode is based on ECB, so the mode must select
ECB otherwise it can fail to initialize.
Signed-off-by: Milan Broz <[email protected]>
---
crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..9c245eb0dd83 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -374,6 +374,7 @@ config CRYPTO_XTS
select CRYPTO_BLKCIPHER
select CRYPTO_MANAGER
select CRYPTO_GF128MUL
+ select CRYPTO_ECB
help
XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain,
key size 256, 384 or 512 bits. This implementation currently
--
2.11.0
On Thu, Feb 23, 2017 at 08:38:26AM +0100, Milan Broz wrote:
> Since the
> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> crypto: xts - Convert to skcipher
> the XTS mode is based on ECB, so the mode must select
> ECB otherwise it can fail to initialize.
>
> Signed-off-by: Milan Broz <[email protected]>
Patch applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Patch below should be backported to 4.10 stable
(only 4.10, older kernels are ok).
We have reports some systems fail to boot from LUKS now
(missing ecb module in initramdisk) ...
Upstream commit is 12cb3a1c4184f891d965d1f39f8cfcc9ef617647
Thanks,
Milan
On 02/23/2017 08:38 AM, Milan Broz wrote:
> Since the
> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> crypto: xts - Convert to skcipher
> the XTS mode is based on ECB, so the mode must select
> ECB otherwise it can fail to initialize.
>
> Signed-off-by: Milan Broz <[email protected]>
> ---
> crypto/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 160f08e721cc..9c245eb0dd83 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -374,6 +374,7 @@ config CRYPTO_XTS
> select CRYPTO_BLKCIPHER
> select CRYPTO_MANAGER
> select CRYPTO_GF128MUL
> + select CRYPTO_ECB
> help
> XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain,
> key size 256, 384 or 512 bits. This implementation currently
>
On Fri, Mar 03, 2017 at 07:25:21AM +0100, Milan Broz wrote:
> Patch below should be backported to 4.10 stable
> (only 4.10, older kernels are ok).
> We have reports some systems fail to boot from LUKS now
> (missing ecb module in initramdisk) ...
>
> Upstream commit is 12cb3a1c4184f891d965d1f39f8cfcc9ef617647
Now queued up, thanks.
greg k-h