Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591695 > unrolled thread

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for  4.10.1. Herbert Xu <herbert@gondor.apana.org.au> - 2017-03-03 08:00 +0100
    Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1. Nathan Royce <nroycea@gmail.com> - 2017-03-03 10:10 +0100
      Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for  4.10.1. Herbert Xu <herbert@gondor.apana.org.au> - 2017-03-03 11:00 +0100
    Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for  4.10.1. Krzysztof Kozlowski <krzk@kernel.org> - 2017-03-05 18:20 +0100

#1591695 — Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> ARM ODroid XU4
> 
> $ cat /proc/config.gz | gunzip | grep XTS
> CONFIG_CRYPTO_XTS=y
> 
> $ grep xts /proc/crypto
> //4.9.13
> name         : xts(aes)
> driver       : xts(aes-generic)
> //4.10.1
> <blank>
> //cbc can be found though
> 
> CRYPTTAB:
> cryptswap1 UUID=<sanitized> /dev/urandom
> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
> 
> FSTAB:
> /dev/mapper/cryptswap1 none swap sw 0 0
> 
> Boot Log:
> [   10.535985] ------------[ cut here ]------------
> [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
> skcipher_walk_first+0x13c/0x14c
> [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> ip_tables x_tables
> [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
> [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   10.574171] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> (show_stack+0x10/0x14)
> [   10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> (dump_stack+0x84/0x98)
> [   10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> (__warn+0xe8/0x100)
> [   10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> (warn_slowpath_null+0x20/0x28)
> [   10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> (skcipher_walk_first+0x13c/0x14c)
> [   10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> (skcipher_walk_virt+0x1c/0x38)
> [   10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> (post_crypt+0x38/0x1c4)
> [   10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> (decrypt_done+0x4c/0x54)
> [   10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> (s5p_aes_complete+0x70/0xfc)
> [   10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> (s5p_aes_interrupt+0x134/0x1a0)
> [   10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> (__handle_irq_event_percpu+0x9c/0x124)

This looks like a bug in the s5p driver.  It's calling the completion
function straight from the IRQ handler, which is triggering the
sanity check in skcipher_walk_first.

The s5p driver needs to schedule a tasklet to call the completion
function.

Do you have crypto self-test enabled? If so it should've caught
this at run-time.  Otherwise you can disable the s5p driver until
it's fixed.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [next] | [standalone]

#1591782 — Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

OK, I went ahead and enabled self tests
"CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
albeit with failures:
*****
Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
test 1 for xts(ecb-aes-s5p): ret=35
Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
Error allocating crypto tfm
Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
target to table
Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
with key file '/dev/urandom': Invalid argument
*****
(weird that it asked for the passphrase)

But I do question whether the root issue is related to s5p... Maybe
there is a correlation in the warning, but to me it looks like the
issue is something else.
In my OP, I noted that the xts crypto isn't even found in /proc/crypto
in 4.10. I'd think it would at least be listed, even if it isn't used.
CBC is listed in /proc/crypto with kernel 4.9.13 and 4.10.1 (cbc-aes-s5p)
XTS is listed in /proc/crypto with kernel 4.9.13 but NOT 4.10.1

I should also add that I didn't include other tainted messages since
they followed the messages I first posted.
I was assuming that when the first issue would work, the others would
follow suit. I just didn't want to inundate with possible junk.
I still have the log file if you think it would be helpful to post the rest.

PS: I also noticed the bounce from my first mail submission because I
didn't enable plain-text for the e-mail (marked as spam because the
email contained html). I rectified that for this reply.

On Thu, Mar 2, 2017 at 10:02 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
>> ARM ODroid XU4
>>
>> $ cat /proc/config.gz | gunzip | grep XTS
>> CONFIG_CRYPTO_XTS=y
>>
>> $ grep xts /proc/crypto
>> //4.9.13
>> name         : xts(aes)
>> driver       : xts(aes-generic)
>> //4.10.1
>> <blank>
>> //cbc can be found though
>>
>> CRYPTTAB:
>> cryptswap1 UUID=<sanitized> /dev/urandom
>> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
>>
>> FSTAB:
>> /dev/mapper/cryptswap1 none swap sw 0 0
>>
>> Boot Log:
>> [   10.535985] ------------[ cut here ]------------
>> [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
>> skcipher_walk_first+0x13c/0x14c
>> [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
>> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
>> ip_tables x_tables
>> [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
>> [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [   10.574171] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> (show_stack+0x10/0x14)
>> [   10.581893] [<c010b408>] (show_stack) from [<c036772c>]
>> (dump_stack+0x84/0x98)
>> [   10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
>> (__warn+0xe8/0x100)
>> [   10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
>> (warn_slowpath_null+0x20/0x28)
>> [   10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
>> (skcipher_walk_first+0x13c/0x14c)
>> [   10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
>> (skcipher_walk_virt+0x1c/0x38)
>> [   10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
>> (post_crypt+0x38/0x1c4)
>> [   10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
>> (decrypt_done+0x4c/0x54)
>> [   10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
>> (s5p_aes_complete+0x70/0xfc)
>> [   10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
>> (s5p_aes_interrupt+0x134/0x1a0)
>> [   10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
>> (__handle_irq_event_percpu+0x9c/0x124)
>
> This looks like a bug in the s5p driver.  It's calling the completion
> function straight from the IRQ handler, which is triggering the
> sanity check in skcipher_walk_first.
>
> The s5p driver needs to schedule a tasklet to call the completion
> function.
>
> Do you have crypto self-test enabled? If so it should've caught
> this at run-time.  Otherwise you can disable the s5p driver until
> it's fixed.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [next] | [standalone]

#1591817

On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
> OK, I went ahead and enabled self tests
> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
> albeit with failures:
> *****
> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
> test 1 for xts(ecb-aes-s5p): ret=35
> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
> Error allocating crypto tfm
> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
> target to table
> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
> with key file '/dev/urandom': Invalid argument
> *****
> (weird that it asked for the passphrase)
> 
> But I do question whether the root issue is related to s5p... Maybe
> there is a correlation in the warning, but to me it looks like the
> issue is something else.

I see.  Do you have ECB enabled in your config? The new XTS requires
ECB to be present so that could be your problem.

There is already a patch on its way to stable to add the Kconfig
select on ECB.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [next] | [standalone]

#1592801

On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> > ARM ODroid XU4
> > 
> > $ cat /proc/config.gz | gunzip | grep XTS
> > CONFIG_CRYPTO_XTS=y
> > 
> > $ grep xts /proc/crypto
> > //4.9.13
> > name         : xts(aes)
> > driver       : xts(aes-generic)
> > //4.10.1
> > <blank>
> > //cbc can be found though
> > 
> > CRYPTTAB:
> > cryptswap1 UUID=<sanitized> /dev/urandom
> > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
> > 
> > FSTAB:
> > /dev/mapper/cryptswap1 none swap sw 0 0
> > 
> > Boot Log:
> > [   10.535985] ------------[ cut here ]------------
> > [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
> > skcipher_walk_first+0x13c/0x14c
> > [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
> > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> > ip_tables x_tables
> > [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
> > [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> > [   10.574171] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> > (show_stack+0x10/0x14)
> > [   10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> > (dump_stack+0x84/0x98)
> > [   10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> > (__warn+0xe8/0x100)
> > [   10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> > (warn_slowpath_null+0x20/0x28)
> > [   10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> > (skcipher_walk_first+0x13c/0x14c)
> > [   10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> > (skcipher_walk_virt+0x1c/0x38)
> > [   10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> > (post_crypt+0x38/0x1c4)
> > [   10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> > (decrypt_done+0x4c/0x54)
> > [   10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> > (s5p_aes_complete+0x70/0xfc)
> > [   10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> > (s5p_aes_interrupt+0x134/0x1a0)
> > [   10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> > (__handle_irq_event_percpu+0x9c/0x124)
> 
> This looks like a bug in the s5p driver.  It's calling the completion
> function straight from the IRQ handler, which is triggering the
> sanity check in skcipher_walk_first.
> 
> The s5p driver needs to schedule a tasklet to call the completion
> function.

Tasklet... or threaded IRQ handler maybe? I sent a fix.

BTW, I subscribe the crypto list but I could not find the original email
there.

Best regards,
Krzysztof

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web