cryptsetup fails after linux-imx6-cubox-dt 3.14.14 upgrade

[pg99]

I have tried the 3.14.14-5 kernel, but unfortunately nothing changed.

I did try out something else though: I have booted into the new kernel and created a new luks partition with "cryptsetup luksFormat /dev/sda1". This works without problems. Next I try to open that new volume with "cryptsetup luksOpen /dev/sda1 crypt-sda1", but it fails!. If I then reboot to 3.10.30-30 kernel it is also not able to open the new luks volume. So the 3.14.14-x kernels all seem to fail opening an existing (good) volume that is generated with another system (arch 3.10 kernel, or gentoo 3.16 kernel) AND the arch 3.14 kernels also generate new volumes that can not be opened by itself ,or by another working kernel. In all cases it does NOT show errors, but simply says the password is wrong. I hope this helps at least in ruling out some scenarios.

Also: In my case loging in via ssh still works with the 3.14.14 kernel. So it could be that the problem Geoff encounters is not the same as I have.

Does anybody knonw if in the 3.14 kernel something changed in the crypography parts? Maybe some hardware encryption/decryption was enabled for the imx6 chip?

Along another line of thought: Could it also be an USB issue? I read in multiple places that there are USB issues with the cubox kernel. All the drives I have tried are USB (I do not own an e-sata drive). My USB keyboard works without problems though.

[Geoff]

$this->bbcode_second_pass_quote('pg99', 'A')lso: In my case loging in via ssh still works with the 3.14.14 kernel. So it could be that the problem Geoff encounters is not the same as I have.

[pepedog]

Ok, I found out why
http://www.solid-run.com/community/post ... ml?#p11339
I did a git diff but the patch doesn't cleanly apply to 3.14.14

[pg99]

@Geoff: indeed, I did not modprobe cryptodev. I will try to to that and see if I get the same result. For the cryptsetup part, my disk also uses aes-xts-plain, so that is still strange. Output of 'cryptsetup luksDump /dev/sda':

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
...

@pepedog: You are probably right. I will have a look at those patches and see if I can make it work. What seems odd to me though, is that if the hardware accelarated encryption is not enabled, the software solution should still work right? Does it mean that it tries to do hardware acceleration, and does it wrong? Than maybe a temporary solution could be to disable the hardware acceleration. That is better than the current situation.I'll let you know if I have any success in getting it to work.

[pepedog]

All you need do is NOT modprobe cryptodev, also reinstall regular OpenSSL

[pg99]

In that case my problem does not seem to be related to CAAM/hardware encryption. I never modprobed cyrptodev, and neither was it in my lsmod. I just tried out what happens if I modprobe cryptodev, and I do not notice any difference. LUKS sttill does not mount my drive, and SSH is still working. I have no experience with hardware accelerated encryption, but from the previous posts I gather that to get it working you need to have 'cryptodev' in your kernel enabled (either built in or as module). So for my problem I think it was software all along.

I wanted to double-check if maybe CAAM was built into the 3.14.14 kernel by looking at the config file, but I found out that the IKCONFIG feature is disabled (which provides the very useful /proc/config.gz file containing the kernel config). In 3.10 it was stil enabled. Where should I ask if this feature can be re-enabled?

Are there maybe any pacakges that I should re-install after the 3.10 --> 3.14 kernel upgrade? I tried it with cryptsetup, but that does not make any difference.

To me the problem still smells like the (software) encryption calculations contain a bug. Or the USB connection is delivering faulty data. Does anybody have another suggestion?

Thanks for all the help thus far.

[pepedog]

If you tell me exactly what you want in CONFIG, I will arrange.

[pg99]

The lines that I would like in the config are:

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Following the 'make menuconfig' layout, it is in:

General Setup --->
<*> Kernel .config support
[*] Enable access to .config through /proc/config.gz

It will increase the sice of the kernel by ~26kB. If this is undesirable, I will just figure out where the linux-imx6-cubox-dt package lives and see if the .config is available there (mayb a git repository?). I am new to arch, so it could be that it would be trivial to find it in that location. A quick search didn't get me anywhere though and having the /proc/config.gz is a very nice feature in any case.

[pepedog]

This is done now
https://github.com/archlinuxarm/PKGBUILDs/commit/14929fe54de10455006604f3734b2f67a1005b09

[pg99]

Thanks for enabling the /proc/config.gz!

I just compared the differences between 3.14.14 and 3.10.30 config files. Unfortunately I couldn't find any likely suspects simply by looking at the config file. I will try to set up my cubox for compiling its own kernel and start bisecting.... My first step will likely be to rebuild the 3.10.30 kernel without the caam patch, and see if that works. Than I will build the 3.10.30 kernel with as many options as possible equal to the 3.14 kernel. If that also works, it is not a config problem, but a bug introduced somewhere between 3.14 and 3.10.
If I find anything I'll let you know.