Re: crypto: xts: regression in 4.10

2017-02-22 Thread Nicolas Porcel
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


Re: crypto: xts: regression in 4.10

2017-02-22 Thread Marcelo Cerri
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 
> > 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



signature.asc
Description: PGP signature


Re: crypto: xts: regression in 4.10

2017-02-22 Thread Milan Broz
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 
>> 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