crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

[Eric Wheeler]

Hello all,

We updated from 4.1.17 to 4.1.18 (same .config) and now get the following 
error when trying to open a LUKS volume.  We've reverted to 4.1.17 and it 
still works, so except that I'm not sure which commit caused the problem, 
it is likely one of the recent commits:

When we `cryptsetup luksOpen` the volume we get this:

  Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).  

Note that I do not see any dm-crypto commits so I don't think its a 
dm-crypto issue. 

I'm happy to test, but can someone who knows the crypto stack suggest 
which of these patches I should focus on for testing? These are the 
commits in 4.1.18 that could be relevant:


bd92b10 crypto: algif_hash - wait for crypto_ahash_init() to complete
73f876a crypto: shash - Fix has_key setting
a9c56fd crypto: algif_skcipher - sendmsg SG marking is off by one
5d545a7 crypto: crc32c - Fix crc32c soft dependency
3a1e81a crypto: algif_hash - Fix race condition in hash_check_key
8515819 crypto: af_alg - Forbid bind(2) when nokey child sockets are present
279792e crypto: algif_hash - Remove custom release parent function
99214a2 crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path
e1ed9a4 crypto: algif_hash - Require setkey before accept(2)
c409087 crypto: hash - Add crypto_ahash_has_setkey
92d76b5 crypto: af_alg - Add nokey compatibility path
fa988b3 crypto: af_alg - Fix socket double-free when accept fails
0571ba5 crypto: af_alg - Disallow bind/setkey/... after accept(2)

Thank you for your help!

(My CONFIG_CRYPTO options are below, just in case that helps.)

-Eric

# CONFIG_CRYPTO_SKEIN is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_MCRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=y
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
CONFIG_CRYPTO_SHA1_MB=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=y
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG_HASH=y
CONFIG_CRYPTO_DRBG_CTR=y
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_USER_API_RNG is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
# CONFIG_CRYPTO_DEV_CCP is not set
CONFIG_CRYPTO_DEV_QAT=m
CONFIG_CRYPTO_DEV_QAT_DH895xCC=m



--
Eric Wheeler, President           eWheeler, Inc. dba Global Linux Security
888-LINUX26 (888-546-8926)        Fax: 503-716-3878           PO Box 25107
www.GlobalLinuxSecurity.pro       Linux since 1996!     Portland, OR 97298

Re: crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

[Greg KH]

On Tue, Mar 01, 2016 at 01:32:05AM +0000, Eric Wheeler wrote:
> Hello all,
> 
> We updated from 4.1.17 to 4.1.18 (same .config) and now get the following 
> error when trying to open a LUKS volume.  We've reverted to 4.1.17 and it 
> still works, so except that I'm not sure which commit caused the problem, 
> it is likely one of the recent commits:
> 
> When we `cryptsetup luksOpen` the volume we get this:
> 
>   Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).  
> 
> Note that I do not see any dm-crypto commits so I don't think its a 
> dm-crypto issue. 
> 
> I'm happy to test, but can someone who knows the crypto stack suggest 
> which of these patches I should focus on for testing? These are the 
> commits in 4.1.18 that could be relevant:

There are some pending crypto backports to resolve this that hopefully
will show up in the next release, whenever Sasha gets to it.

thanks,

greg k-h

Re: crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

[Milan Broz]

On 03/01/2016 03:58 AM, Greg KH wrote:
> On Tue, Mar 01, 2016 at 01:32:05AM +0000, Eric Wheeler wrote:
>> Hello all,
>>
>> We updated from 4.1.17 to 4.1.18 (same .config) and now get the following 
>> error when trying to open a LUKS volume.  We've reverted to 4.1.17 and it 
>> still works, so except that I'm not sure which commit caused the problem, 
>> it is likely one of the recent commits:
>>
>> When we `cryptsetup luksOpen` the volume we get this:
>>
>>   Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).  
>>
>> Note that I do not see any dm-crypto commits so I don't think its a 
>> dm-crypto issue. 
>>
>> I'm happy to test, but can someone who knows the crypto stack suggest 
>> which of these patches I should focus on for testing? These are the 
>> commits in 4.1.18 that could be relevant:
> 
> There are some pending crypto backports to resolve this that hopefully
> will show up in the next release, whenever Sasha gets to it.

Also there is already released cryptsetup 1.7.1 that works even with this kernel.

Milan

Re: crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

[Eric Wheeler]

On Wed, 2 Mar 2016, Milan Broz wrote:

> On 03/01/2016 03:58 AM, Greg KH wrote:
> > On Tue, Mar 01, 2016 at 01:32:05AM +0000, Eric Wheeler wrote:
> >> Hello all,
> >>
> >> We updated from 4.1.17 to 4.1.18 (same .config) and now get the following 
> >> error when trying to open a LUKS volume.  We've reverted to 4.1.17 and it 
> >> still works, so except that I'm not sure which commit caused the problem, 
> >> it is likely one of the recent commits:
> >>
> >> When we `cryptsetup luksOpen` the volume we get this:
> >>
> >>   Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).  
> >>
> >> Note that I do not see any dm-crypto commits so I don't think its a 
> >> dm-crypto issue. 
> >>
> >> I'm happy to test, but can someone who knows the crypto stack suggest 
> >> which of these patches I should focus on for testing? These are the 
> >> commits in 4.1.18 that could be relevant:
> > 
> > There are some pending crypto backports to resolve this that hopefully
> > will show up in the next release, whenever Sasha gets to it.
> 
> Also there is already released cryptsetup 1.7.1 that works even with this kernel.

Interesting.  API change?  I'd like to read up on it.  Is there a commit 
or mailing thread on the topic?

-Eric

> 
> Milan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: crypto regression in 4.1.18: Check that kernel supports aes-cbc-essiv:sha256 cipher

[Eric Wheeler]

On Tue, 1 Mar 2016, Greg KH wrote:
> On Tue, Mar 01, 2016 at 01:32:05AM +0000, Eric Wheeler wrote:
> > Hello all,
> > 
> > We updated from 4.1.17 to 4.1.18 (same .config) and now get the following 
> > error when trying to open a LUKS volume.  We've reverted to 4.1.17 and it 
> > still works, so except that I'm not sure which commit caused the problem, 
> > it is likely one of the recent commits:
> > 
> > When we `cryptsetup luksOpen` the volume we get this:
> > 
> >   Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).  
> > 
> > Note that I do not see any dm-crypto commits so I don't think its a 
> > dm-crypto issue. 
> > 
> > I'm happy to test, but can someone who knows the crypto stack suggest 
> > which of these patches I should focus on for testing? These are the 
> > commits in 4.1.18 that could be relevant:
> 
> There are some pending crypto backports to resolve this that hopefully
> will show up in the next release, whenever Sasha gets to it.

Thanks Greg.

Confirmed fixed in 4.1.19.

-Eric

> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>