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
http://www.GlobalLinuxSecurity.pro Linux since 1996! Portland, OR 97298
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>