Control: tag -1 moreinfo Control: severity -1 important On Sun, 2016-01-31 at 16:03 +0100, Carsten Wolff wrote: > Package: src:linux > Version: 3.16.7-ckt20-1+deb8u3 > Severity: normal > > Hi, > > I'm not at all sure I'm filing this against the right package. Maybe > cryptsetup, maybe linux, ... > > After upgrading this system from wheezy to jessie, unlocking the cryptroot from > initrd with padlock-aes and padlock-sha loaded stopped working. After entering > the passphrase, cryptsetup fails with a message like > "cryptsetup check that kernel supports aes-cbc-essiv:sha265" > > In dmesg, there's another message: > [ 233.196927] alg: skcipher: Result buffer corruption in chunk test 1 on encryption at page 0 for cbc-aes-padlock: 32 bytes: > [ 233.196998] 00000000: 4f 1c 0e cd 0b 96 fd bf 26 50 95 5f 63 a6 7e eb > [ 233.197007] 00000010: f2 01 6e 42 a4 8f 6f 86 d3 c6 17 85 4a d4 1d 71 > [ 233.202194] device-mapper: table: 254:0: crypt: Error allocating crypto tfm > [ 233.202259] device-mapper: ioctl: error adding target to table > > Things I found out so far: > - booting with latest wheezy kernel (initrd updated by jessie): works, with padlock support. > - from initrd, rmmod padlock-aes and padlock-sha, then modprobe sha256 and cbc, > then luksOpen: works (slower, of course). > - The code generating the "alg: skcipher:"-message is in crypto/testmgr.c and > it seems, these lines have only be changed in one commit between 3.2 and > 3.16: > https://github.com/torvalds/linux/commit/08d6af8c160b6bd9b21a3177e2b1bebc72a21041 > > Any ideas? That suggests a regression in the padlock-aes driver, although I don't see any functional changes there. As a workaround, you can blacklist it by adding "blacklist=padlock-aes" to the kernel command line. I wonder whether the compiler version makes a difference. Does the 3.16 kernel in the wheezy-backports suite behave any differently? Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false.
Attachment:
signature.asc
Description: This is a digitally signed message part