* crypto: hang in crypto_larval_lookup
@ 2017-02-17 17:50 Harald Freudenberger
2017-02-23 11:19 ` Herbert Xu
0 siblings, 1 reply; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-17 17:50 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, Martin Schwidefsky
Hello all
I am currently following a hang at modprobe aes_s390 where
crypto_register_alg() does not come back for the xts(aes) algorithm.
The registration is waiting forever in algapi.c crypto_wait_for_test() but
the completion never occurs. The cryptomgr is triggering a test via
kthread_run to invoce cryptomgr_probe and this thread is calling the
create() function of the xts template (file xts.c). Following this thread
it comes down to api.c crypto_larval_lookup(name="aes") which is first
requesting the module "crypto-aes" via request_module() successful and then
blocking forever in requesting the module "crypto-aes-all".
The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
This problem is seen since about 6 weeks now, first only on the linux next
kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
idea on how this could be fixed or what's wrong with just the xts
registration (ecb, cbc, ctr work fine).
Any ideas or hints?
Thank's in advance.
regards
Harald Freudenberger
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-17 17:50 crypto: hang in crypto_larval_lookup Harald Freudenberger
@ 2017-02-23 11:19 ` Herbert Xu
2017-02-23 11:39 ` Herbert Xu
0 siblings, 1 reply; 13+ messages in thread
From: Herbert Xu @ 2017-02-23 11:19 UTC (permalink / raw)
To: Harald Freudenberger; +Cc: linux-crypto, schwidefsky
Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
>
> Hello all
>
> I am currently following a hang at modprobe aes_s390 where
> crypto_register_alg() does not come back for the xts(aes) algorithm.
>
> The registration is waiting forever in algapi.c crypto_wait_for_test() but
> the completion never occurs. The cryptomgr is triggering a test via
> kthread_run to invoce cryptomgr_probe and this thread is calling the
> create() function of the xts template (file xts.c). Following this thread
> it comes down to api.c crypto_larval_lookup(name="aes") which is first
> requesting the module "crypto-aes" via request_module() successful and then
> blocking forever in requesting the module "crypto-aes-all".
>
> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
>
> This problem is seen since about 6 weeks now, first only on the linux next
> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
> idea on how this could be fixed or what's wrong with just the xts
> registration (ecb, cbc, ctr work fine).
>
> Any ideas or hints?
Sorry, my fault. I should've converted all the fallback users of
the old blkcipher interface over to skcipher before converting the
core algorithms to skcipher.
I'll send a patch.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-23 11:19 ` Herbert Xu
@ 2017-02-23 11:39 ` Herbert Xu
2017-02-23 16:02 ` Harald Freudenberger
2017-02-24 23:44 ` Marcelo Cerri
0 siblings, 2 replies; 13+ messages in thread
From: Herbert Xu @ 2017-02-23 11:39 UTC (permalink / raw)
To: Harald Freudenberger; +Cc: linux-crypto, schwidefsky
On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
> Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
> >
> > Hello all
> >
> > I am currently following a hang at modprobe aes_s390 where
> > crypto_register_alg() does not come back for the xts(aes) algorithm.
> >
> > The registration is waiting forever in algapi.c crypto_wait_for_test() but
> > the completion never occurs. The cryptomgr is triggering a test via
> > kthread_run to invoce cryptomgr_probe and this thread is calling the
> > create() function of the xts template (file xts.c). Following this thread
> > it comes down to api.c crypto_larval_lookup(name="aes") which is first
> > requesting the module "crypto-aes" via request_module() successful and then
> > blocking forever in requesting the module "crypto-aes-all".
> >
> > The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
> >
> > This problem is seen since about 6 weeks now, first only on the linux next
> > kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
> > idea on how this could be fixed or what's wrong with just the xts
> > registration (ecb, cbc, ctr work fine).
> >
> > Any ideas or hints?
>
> Sorry, my fault. I should've converted all the fallback users of
> the old blkcipher interface over to skcipher before converting the
> core algorithms to skcipher.
>
> I'll send a patch.
Hmm, actually looks like I did convert this one :)
Do you have ECB enabled in your configuration? XTS doesn't work
without it. Currently the Kconfig is missing a select on ECB so
it could stop the generic XTS from loading.
However, you seem to be stuck on straight AES which quite strange.
The reason is that s390 crypto registers AES as the first thing so
it should already be available.
The fact that it hangs is expected because it's trying to find
an acceptable AES implementation and in doing so it's loading
s390-aes again.
So we need to get to the bottom of why there is no acceptable
"aes" registered. Can you check /proc/crypto to see if the simple
aes cipher is correctly registered (passing the selftest) after
it hangs?
You could also print out the type/mask in crypto_larval_lookup
to see if perhaps the caller is asking for something unreasonable.
Thanks,
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-23 11:39 ` Herbert Xu
@ 2017-02-23 16:02 ` Harald Freudenberger
2017-02-24 8:42 ` Harald Freudenberger
2017-02-24 23:44 ` Marcelo Cerri
1 sibling, 1 reply; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-23 16:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, schwidefsky
On 02/23/2017 12:39 PM, Herbert Xu wrote:
> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>> Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
>>> Hello all
>>>
>>> I am currently following a hang at modprobe aes_s390 where
>>> crypto_register_alg() does not come back for the xts(aes) algorithm.
>>>
>>> The registration is waiting forever in algapi.c crypto_wait_for_test() but
>>> the completion never occurs. The cryptomgr is triggering a test via
>>> kthread_run to invoce cryptomgr_probe and this thread is calling the
>>> create() function of the xts template (file xts.c). Following this thread
>>> it comes down to api.c crypto_larval_lookup(name="aes") which is first
>>> requesting the module "crypto-aes" via request_module() successful and then
>>> blocking forever in requesting the module "crypto-aes-all".
>>>
>>> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
>>>
>>> This problem is seen since about 6 weeks now, first only on the linux next
>>> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
>>> idea on how this could be fixed or what's wrong with just the xts
>>> registration (ecb, cbc, ctr work fine).
>>>
>>> Any ideas or hints?
>> Sorry, my fault. I should've converted all the fallback users of
>> the old blkcipher interface over to skcipher before converting the
>> core algorithms to skcipher.
>>
>> I'll send a patch.
> Hmm, actually looks like I did convert this one :)
>
> Do you have ECB enabled in your configuration? XTS doesn't work
> without it. Currently the Kconfig is missing a select on ECB so
> it could stop the generic XTS from loading.
>
> However, you seem to be stuck on straight AES which quite strange.
> The reason is that s390 crypto registers AES as the first thing so
> it should already be available.
>
> The fact that it hangs is expected because it's trying to find
> an acceptable AES implementation and in doing so it's loading
> s390-aes again.
>
> So we need to get to the bottom of why there is no acceptable
> "aes" registered. Can you check /proc/crypto to see if the simple
> aes cipher is correctly registered (passing the selftest) after
> it hangs?
>
> You could also print out the type/mask in crypto_larval_lookup
> to see if perhaps the caller is asking for something unreasonable.
>
> Thanks,
Thanks for your help, here is cat /proc/crypto:
name : xts(aes)
driver :
module : kernel
priority : -1
refcnt : 3
selftest : passed
internal : no
type : larval
flags : 0x415
name : xts(aes)
driver : xts-aes-s390
module : kernel
priority : 400
refcnt : 1
selftest : passed
internal : no
type : larval
flags : 0x514
name : xts(aes)
driver : xts-aes-s390
module : aes_s390
priority : 400
refcnt : 4
selftest : unknown
internal : no
type : blkcipher
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
...
name : ecb(aes)
driver : ecb(aes-s390)
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 0
geniv : <default>
name : ecb(aes)
driver : ecb-aes-s390
module : aes_s390
priority : 400
refcnt : 1
selftest : passed
internal : no
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 0
geniv : <default>
name : aes
driver : aes-s390
module : aes_s390
priority : 300
refcnt : 1
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
...
at the time where the modprobe hangs.
And here is some syslog output (I added some printks for debugging) maybe
it may give you some hints about whats going on during the modprobe:
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3)
Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1)
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390)
Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts-aes-s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120
Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4
Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes))
Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes))
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes))
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes))
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes))
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8
Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8)
Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3
Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8)
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts)
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00
Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11
Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts)
Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
--- modprobe aes_s390 hang ---
regards H.Freudenberger
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-23 16:02 ` Harald Freudenberger
@ 2017-02-24 8:42 ` Harald Freudenberger
2017-02-24 10:32 ` Harald Freudenberger
0 siblings, 1 reply; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-24 8:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, schwidefsky
On 02/23/2017 05:02 PM, Harald Freudenberger wrote:
> On 02/23/2017 12:39 PM, Herbert Xu wrote:
>> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>>> Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
>>>> Hello all
>>>>
>>>> I am currently following a hang at modprobe aes_s390 where
>>>> crypto_register_alg() does not come back for the xts(aes) algorithm.
>>>>
>>>> The registration is waiting forever in algapi.c crypto_wait_for_test() but
>>>> the completion never occurs. The cryptomgr is triggering a test via
>>>> kthread_run to invoce cryptomgr_probe and this thread is calling the
>>>> create() function of the xts template (file xts.c). Following this thread
>>>> it comes down to api.c crypto_larval_lookup(name="aes") which is first
>>>> requesting the module "crypto-aes" via request_module() successful and then
>>>> blocking forever in requesting the module "crypto-aes-all".
>>>>
>>>> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
>>>>
>>>> This problem is seen since about 6 weeks now, first only on the linux next
>>>> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
>>>> idea on how this could be fixed or what's wrong with just the xts
>>>> registration (ecb, cbc, ctr work fine).
>>>>
>>>> Any ideas or hints?
>>> Sorry, my fault. I should've converted all the fallback users of
>>> the old blkcipher interface over to skcipher before converting the
>>> core algorithms to skcipher.
>>>
>>> I'll send a patch.
>> Hmm, actually looks like I did convert this one :)
>>
>> Do you have ECB enabled in your configuration? XTS doesn't work
>> without it. Currently the Kconfig is missing a select on ECB so
>> it could stop the generic XTS from loading.
>>
>> However, you seem to be stuck on straight AES which quite strange.
>> The reason is that s390 crypto registers AES as the first thing so
>> it should already be available.
>>
>> The fact that it hangs is expected because it's trying to find
>> an acceptable AES implementation and in doing so it's loading
>> s390-aes again.
>>
>> So we need to get to the bottom of why there is no acceptable
>> "aes" registered. Can you check /proc/crypto to see if the simple
>> aes cipher is correctly registered (passing the selftest) after
>> it hangs?
>>
>> You could also print out the type/mask in crypto_larval_lookup
>> to see if perhaps the caller is asking for something unreasonable.
>>
>> Thanks,
> Thanks for your help, here is cat /proc/crypto:
> name : xts(aes)
> driver :
> module : kernel
> priority : -1
> refcnt : 3
> selftest : passed
> internal : no
> type : larval
> flags : 0x415
>
> name : xts(aes)
> driver : xts-aes-s390
> module : kernel
> priority : 400
> refcnt : 1
> selftest : passed
> internal : no
> type : larval
> flags : 0x514
>
> name : xts(aes)
> driver : xts-aes-s390
> module : aes_s390
> priority : 400
> refcnt : 4
> selftest : unknown
> internal : no
> type : blkcipher
> blocksize : 16
> min keysize : 32
> max keysize : 64
> ivsize : 16
> geniv : <default>
>
> ...
>
> name : ecb(aes)
> driver : ecb(aes-s390)
> module : kernel
> priority : 300
> refcnt : 1
> selftest : passed
> internal : no
> type : blkcipher
> blocksize : 16
> min keysize : 16
> max keysize : 32
> ivsize : 0
> geniv : <default>
>
> name : ecb(aes)
> driver : ecb-aes-s390
> module : aes_s390
> priority : 400
> refcnt : 1
> selftest : passed
> internal : no
> type : blkcipher
> blocksize : 16
> min keysize : 16
> max keysize : 32
> ivsize : 0
> geniv : <default>
>
> name : aes
> driver : aes-s390
> module : aes_s390
> priority : 300
> refcnt : 1
> selftest : passed
> internal : no
> type : cipher
> blocksize : 16
> min keysize : 16
> max keysize : 32
> ...
>
> at the time where the modprobe hangs.
>
> And here is some syslog output (I added some printks for debugging) maybe
> it may give you some hints about whats going on during the modprobe:
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3)
> Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1)
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390)
> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts-aes-s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120
> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4
> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8
> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8)
> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3
> Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8)
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts)
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00
> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11
> Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts)
> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
> --- modprobe aes_s390 hang ---
>
> regards H.Freudenberger
>
Here are the type and mask values:
...
Feb 24 09:28:10 r35lp49 kernel: ->crypto_larval_lookup(name=aes,type=0x00000405,mask=0x0000248c)
Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(aes,0x00000405,0x0000248c)
Feb 24 09:28:10 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
Feb 24 09:28:10 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
type=0x00000405 = CRYPTO_ALG_TESTED, CRYPTO_ALG_TYPE_SKCIPHER
mask=0x0000248c = CRYPTO_ALG_INTERNAL, CRYPTO_ALG_TESTED, CRYPTO_ALG_ASYNC, CRYPTO_ALG_TYPE_BLKCIPHER_MASK
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-24 8:42 ` Harald Freudenberger
@ 2017-02-24 10:32 ` Harald Freudenberger
2017-02-24 11:21 ` Harald Freudenberger
0 siblings, 1 reply; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-24 10:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, schwidefsky
On 02/24/2017 09:42 AM, Harald Freudenberger wrote:
> On 02/23/2017 05:02 PM, Harald Freudenberger wrote:
>> On 02/23/2017 12:39 PM, Herbert Xu wrote:
>>> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>>>> Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
>>>>> Hello all
>>>>>
>>>>> I am currently following a hang at modprobe aes_s390 where
>>>>> crypto_register_alg() does not come back for the xts(aes) algorithm.
>>>>>
>>>>> The registration is waiting forever in algapi.c crypto_wait_for_test() but
>>>>> the completion never occurs. The cryptomgr is triggering a test via
>>>>> kthread_run to invoce cryptomgr_probe and this thread is calling the
>>>>> create() function of the xts template (file xts.c). Following this thread
>>>>> it comes down to api.c crypto_larval_lookup(name="aes") which is first
>>>>> requesting the module "crypto-aes" via request_module() successful and then
>>>>> blocking forever in requesting the module "crypto-aes-all".
>>>>>
>>>>> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
>>>>>
>>>>> This problem is seen since about 6 weeks now, first only on the linux next
>>>>> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
>>>>> idea on how this could be fixed or what's wrong with just the xts
>>>>> registration (ecb, cbc, ctr work fine).
>>>>>
>>>>> Any ideas or hints?
>>>> Sorry, my fault. I should've converted all the fallback users of
>>>> the old blkcipher interface over to skcipher before converting the
>>>> core algorithms to skcipher.
>>>>
>>>> I'll send a patch.
>>> Hmm, actually looks like I did convert this one :)
>>>
>>> Do you have ECB enabled in your configuration? XTS doesn't work
>>> without it. Currently the Kconfig is missing a select on ECB so
>>> it could stop the generic XTS from loading.
>>>
>>> However, you seem to be stuck on straight AES which quite strange.
>>> The reason is that s390 crypto registers AES as the first thing so
>>> it should already be available.
>>>
>>> The fact that it hangs is expected because it's trying to find
>>> an acceptable AES implementation and in doing so it's loading
>>> s390-aes again.
>>>
>>> So we need to get to the bottom of why there is no acceptable
>>> "aes" registered. Can you check /proc/crypto to see if the simple
>>> aes cipher is correctly registered (passing the selftest) after
>>> it hangs?
>>>
>>> You could also print out the type/mask in crypto_larval_lookup
>>> to see if perhaps the caller is asking for something unreasonable.
>>>
>>> Thanks,
>> Thanks for your help, here is cat /proc/crypto:
>> name : xts(aes)
>> driver :
>> module : kernel
>> priority : -1
>> refcnt : 3
>> selftest : passed
>> internal : no
>> type : larval
>> flags : 0x415
>>
>> name : xts(aes)
>> driver : xts-aes-s390
>> module : kernel
>> priority : 400
>> refcnt : 1
>> selftest : passed
>> internal : no
>> type : larval
>> flags : 0x514
>>
>> name : xts(aes)
>> driver : xts-aes-s390
>> module : aes_s390
>> priority : 400
>> refcnt : 4
>> selftest : unknown
>> internal : no
>> type : blkcipher
>> blocksize : 16
>> min keysize : 32
>> max keysize : 64
>> ivsize : 16
>> geniv : <default>
>>
>> ...
>>
>> name : ecb(aes)
>> driver : ecb(aes-s390)
>> module : kernel
>> priority : 300
>> refcnt : 1
>> selftest : passed
>> internal : no
>> type : blkcipher
>> blocksize : 16
>> min keysize : 16
>> max keysize : 32
>> ivsize : 0
>> geniv : <default>
>>
>> name : ecb(aes)
>> driver : ecb-aes-s390
>> module : aes_s390
>> priority : 400
>> refcnt : 1
>> selftest : passed
>> internal : no
>> type : blkcipher
>> blocksize : 16
>> min keysize : 16
>> max keysize : 32
>> ivsize : 0
>> geniv : <default>
>>
>> name : aes
>> driver : aes-s390
>> module : aes_s390
>> priority : 300
>> refcnt : 1
>> selftest : passed
>> internal : no
>> type : cipher
>> blocksize : 16
>> min keysize : 16
>> max keysize : 32
>> ...
>>
>> at the time where the modprobe hangs.
>>
>> And here is some syslog output (I added some printks for debugging) maybe
>> it may give you some hints about whats going on during the modprobe:
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
>> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3)
>> Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=0000000000f2dd68 alg.cra_refcnt=2
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68
>> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic, alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390)
>> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts-aes-s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120
>> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4
>> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes))
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null)
>> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8
>> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8)
>> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3
>> Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8)
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts)
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00
>> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11
>> Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup()
>> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
>> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
>> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
>> --- modprobe aes_s390 hang ---
>>
>> regards H.Freudenberger
>>
> Here are the type and mask values:
>
> ...
> Feb 24 09:28:10 r35lp49 kernel: ->crypto_larval_lookup(name=aes,type=0x00000405,mask=0x0000248c)
> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(aes,0x00000405,0x0000248c)
> Feb 24 09:28:10 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
> Feb 24 09:28:10 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
>
> type=0x00000405 = CRYPTO_ALG_TESTED, CRYPTO_ALG_TYPE_SKCIPHER
> mask=0x0000248c = CRYPTO_ALG_INTERNAL, CRYPTO_ALG_TESTED, CRYPTO_ALG_ASYNC, CRYPTO_ALG_TYPE_BLKCIPHER_MASK
>
I catched it: Thanks Herbert for your hint. The aes algorith registers with:
.cra_flags = CRYPTO_ALG_TYPE_CIPHER |CRYPTO_ALG_NEED_FALLBACK
so later at __crypto_alg_lookup(aes, 0x0405, 0x248c)
this alg is not choosen because the check
if ((q->cra_flags ^ type) & mask)
is true q->cra_flags = 0x0501 ^ 0x0405 & 0x248x => 0x0004
@Martin, I'll commit a patch asap.
Thanks for your help :-)
regards, H.Freudenberger
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-24 10:32 ` Harald Freudenberger
@ 2017-02-24 11:21 ` Harald Freudenberger
0 siblings, 0 replies; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-24 11:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, schwidefsky
On 02/24/2017 11:32 AM, Harald Freudenberger wrote:
> On 02/24/2017 09:42 AM, Harald Freudenberger wrote:
...
>> ...
>> Feb 24 09:28:10 r35lp49 kernel: ->crypto_larval_lookup(name=aes,type=0x00000405,mask=0x0000248c)
>> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(aes,0x00000405,0x0000248c)
>> Feb 24 09:28:10 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
>> Feb 24 09:28:10 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg= (null)
>> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes)
>> Feb 24 09:28:10 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all)
>>
>> type=0x00000405 = CRYPTO_ALG_TESTED, CRYPTO_ALG_TYPE_SKCIPHER
>> mask=0x0000248c = CRYPTO_ALG_INTERNAL, CRYPTO_ALG_TESTED, CRYPTO_ALG_ASYNC, CRYPTO_ALG_TYPE_BLKCIPHER_MASK
>>
> I catched it: Thanks Herbert for your hint. The aes algorith registers with:
> .cra_flags = CRYPTO_ALG_TYPE_CIPHER |CRYPTO_ALG_NEED_FALLBACK
> so later at __crypto_alg_lookup(aes, 0x0405, 0x248c)
> this alg is not choosen because the check
> if ((q->cra_flags ^ type) & mask)
> is true q->cra_flags = 0x0501 ^ 0x0405 & 0x248x => 0x0004
>
> @Martin, I'll commit a patch asap.
>
> Thanks for your help :-)
>
> regards, H.Freudenberger
>
rollback. Changing the cra_flag CRYPTO_ALG_TYPE_SKCIPHER in the crypto_alg
registration struct is not the right way.
continuing evaluation ...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-23 11:39 ` Herbert Xu
2017-02-23 16:02 ` Harald Freudenberger
@ 2017-02-24 23:44 ` Marcelo Cerri
2017-02-25 15:17 ` Herbert Xu
1 sibling, 1 reply; 13+ messages in thread
From: Marcelo Cerri @ 2017-02-24 23:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: Harald Freudenberger, linux-crypto, schwidefsky
[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]
On Thu, Feb 23, 2017 at 07:39:09PM +0800, Herbert Xu wrote:
> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
> > Harald Freudenberger <freude@linux.vnet.ibm.com> wrote:
> > >
> > > Hello all
> > >
> > > I am currently following a hang at modprobe aes_s390 where
> > > crypto_register_alg() does not come back for the xts(aes) algorithm.
> > >
> > > The registration is waiting forever in algapi.c crypto_wait_for_test() but
> > > the completion never occurs. The cryptomgr is triggering a test via
> > > kthread_run to invoce cryptomgr_probe and this thread is calling the
> > > create() function of the xts template (file xts.c). Following this thread
> > > it comes down to api.c crypto_larval_lookup(name="aes") which is first
> > > requesting the module "crypto-aes" via request_module() successful and then
> > > blocking forever in requesting the module "crypto-aes-all".
> > >
> > > The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
> > >
> > > This problem is seen since about 6 weeks now, first only on the linux next
> > > kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
> > > idea on how this could be fixed or what's wrong with just the xts
> > > registration (ecb, cbc, ctr work fine).
> > >
> > > Any ideas or hints?
> >
> > Sorry, my fault. I should've converted all the fallback users of
> > the old blkcipher interface over to skcipher before converting the
> > core algorithms to skcipher.
> >
> > I'll send a patch.
>
> Hmm, actually looks like I did convert this one :)
>
> Do you have ECB enabled in your configuration? XTS doesn't work
> without it. Currently the Kconfig is missing a select on ECB so
> it could stop the generic XTS from loading.
>
> However, you seem to be stuck on straight AES which quite strange.
> The reason is that s390 crypto registers AES as the first thing so
> it should already be available.
>
> The fact that it hangs is expected because it's trying to find
> an acceptable AES implementation and in doing so it's loading
> s390-aes again.
>
> So we need to get to the bottom of why there is no acceptable
> "aes" registered. Can you check /proc/crypto to see if the simple
> aes cipher is correctly registered (passing the selftest) after
> it hangs?
This is probably caused by the way that the xts template is handling the
underline algorithm selection.
In the create function in crypto/xts.c:
static int create(struct crypto_template *tmpl, struct rtattr **tb)
{
...
crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst));
err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0,
crypto_requires_sync(algt->type,
algt->mask));
if (err == -ENOENT) {
err = -ENAMETOOLONG;
if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)",
cipher_name) >= CRYPTO_MAX_ALG_NAME)
goto err_free_inst;
err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0,
crypto_requires_sync(algt->type,
algt->mask));
}
...
Then when the aes_s390 driver tries to allocate its fallback based on
its name ("xts(aes)"), the xts template will first look for an skcipher
"aes" algorithm, that doesn't exist. And because of that
crypto_larval_lookup will try to load the correspondent alias. Also,
since the template does not use the requested flag
CRYPTO_ALG_NEED_FALLBACK when it selects the underline algorithm, the
-all alias is also requested.
A simple workaround is to try the ecb algorithm before the original
algorithm. However this still can lead to the same problem when no ecb
implementation is available, not even by the driver itself.
Another improvement that can be useful is to honor the requested
CRYPTO_ALG_NEED_FALLBACK flag when selecting the underline algorithm.
It's very likely that the aes_s390 driver will end up using the
following chain of fallback algorithms:
xts-aes-s390 -> xts(ecb-aes-s390) -> xts(ecb(aes-s390)) ->
xts(ecb(aes-generic))
A similar scenario occurs for the vmx-crypto driver.
>
> You could also print out the type/mask in crypto_larval_lookup
> to see if perhaps the caller is asking for something unreasonable.
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/1111
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-24 23:44 ` Marcelo Cerri
@ 2017-02-25 15:17 ` Herbert Xu
2017-02-25 19:20 ` Marcelo Cerri
0 siblings, 1 reply; 13+ messages in thread
From: Herbert Xu @ 2017-02-25 15:17 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky
On Fri, Feb 24, 2017 at 08:44:00PM -0300, Marcelo Cerri wrote:
>
> This is probably caused by the way that the xts template is handling the
> underline algorithm selection.
Good catch. I think the bigger issue here is that when requesting
for an XTS that doesn't need a fallback we shouldn't be using an
underlying ECB that needs one. So this patch should fix the hang.
Thanks,
---8<---
Subject: crypto: xts - Propagate NEED_FALLBACK bit
When we're used as a fallback algorithm, we should propagate
the NEED_FALLBACK bit when searching for the underlying ECB mode.
This just happens to fix a hang too because otherwise the search
may end up loading the same module that triggered this XTS creation.
Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/xts.c b/crypto/xts.c
index 410a2e2..2066161 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
struct xts_instance_ctx *ctx;
struct skcipher_alg *alg;
const char *cipher_name;
+ u32 mask;
int err;
algt = crypto_get_attr_type(tb);
@@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
ctx = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+
+ mask = crypto_requires_sync(algt->type, algt->mask) |
+ ((algt->type ^ CRYPTO_ALG_NEED_FALLBACK) & algt->mask &
+ CRYPTO_ALG_NEED_FALLBACK);
+
+ err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask);
if (err == -ENOENT) {
err = -ENAMETOOLONG;
if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)",
cipher_name) >= CRYPTO_MAX_ALG_NAME)
goto err_free_inst;
- err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask);
}
if (err)
--
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-25 15:17 ` Herbert Xu
@ 2017-02-25 19:20 ` Marcelo Cerri
2017-02-26 4:22 ` Herbert Xu
0 siblings, 1 reply; 13+ messages in thread
From: Marcelo Cerri @ 2017-02-25 19:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: Harald Freudenberger, linux-crypto, schwidefsky
[-- Attachment #1: Type: text/plain, Size: 3093 bytes --]
On Sat, Feb 25, 2017 at 11:17:07PM +0800, Herbert Xu wrote:
> On Fri, Feb 24, 2017 at 08:44:00PM -0300, Marcelo Cerri wrote:
> >
> > This is probably caused by the way that the xts template is handling the
> > underline algorithm selection.
>
> Good catch. I think the bigger issue here is that when requesting
> for an XTS that doesn't need a fallback we shouldn't be using an
> underlying ECB that needs one. So this patch should fix the hang.
Yeah, I agree. This should work as long as the module aliases are
correct, which is enough.
Other templates will not trigger the same error since they don't have to
try more than one underlying algorithm. But I think this is still
desirable for the remaining templates to avoid a long chain of unused
fallbacks as in the example I gave in my previous email.
Probably a helper function to return the correct mask might be useful
for readability and to avoid duplicate code.
>
> Thanks,
>
> ---8<---
> Subject: crypto: xts - Propagate NEED_FALLBACK bit
>
> When we're used as a fallback algorithm, we should propagate
> the NEED_FALLBACK bit when searching for the underlying ECB mode.
>
> This just happens to fix a hang too because otherwise the search
> may end up loading the same module that triggered this XTS creation.
>
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/xts.c b/crypto/xts.c
> index 410a2e2..2066161 100644
> --- a/crypto/xts.c
> +++ b/crypto/xts.c
> @@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
> struct xts_instance_ctx *ctx;
> struct skcipher_alg *alg;
> const char *cipher_name;
> + u32 mask;
> int err;
>
> algt = crypto_get_attr_type(tb);
> @@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
> ctx = skcipher_instance_ctx(inst);
>
> crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst));
> - err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0,
> - crypto_requires_sync(algt->type,
> - algt->mask));
> +
> + mask = crypto_requires_sync(algt->type, algt->mask) |
> + ((algt->type ^ CRYPTO_ALG_NEED_FALLBACK) & algt->mask &
> + CRYPTO_ALG_NEED_FALLBACK);
> +
> + err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask);
> if (err == -ENOENT) {
> err = -ENAMETOOLONG;
> if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)",
> cipher_name) >= CRYPTO_MAX_ALG_NAME)
> goto err_free_inst;
>
> - err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0,
> - crypto_requires_sync(algt->type,
> - algt->mask));
> + err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask);
> }
>
> if (err)
> --
> 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
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-25 19:20 ` Marcelo Cerri
@ 2017-02-26 4:22 ` Herbert Xu
2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu
2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger
0 siblings, 2 replies; 13+ messages in thread
From: Herbert Xu @ 2017-02-26 4:22 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky
On Sat, Feb 25, 2017 at 04:20:22PM -0300, Marcelo Cerri wrote:
>
> Yeah, I agree. This should work as long as the module aliases are
> correct, which is enough.
>
> Other templates will not trigger the same error since they don't have to
> try more than one underlying algorithm. But I think this is still
> desirable for the remaining templates to avoid a long chain of unused
> fallbacks as in the example I gave in my previous email.
>
> Probably a helper function to return the correct mask might be useful
> for readability and to avoid duplicate code.
You're right. Here is a patch to add a helper for this.
Thanks!
---8<---
Subject: crypto: api - Add crypto_requires_off helper
This patch adds crypto_requires_off which is an extension of
crypto_requires_sync for similar bits such as NEED_FALLBACK.
Suggested-by: Marcelo Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index ebe4ded..436c4c2 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -360,13 +360,18 @@ static inline struct crypto_alg *crypto_get_attr_alg(struct rtattr **tb,
return crypto_attr_alg(tb[1], type, mask);
}
+static inline int crypto_requires_off(u32 type, u32 mask, u32 off)
+{
+ return (type ^ off) & mask & off;
+}
+
/*
* Returns CRYPTO_ALG_ASYNC if type/mask requires the use of sync algorithms.
* Otherwise returns zero.
*/
static inline int crypto_requires_sync(u32 type, u32 mask)
{
- return (type ^ CRYPTO_ALG_ASYNC) & mask & CRYPTO_ALG_ASYNC;
+ return crypto_requires_off(type, mask, CRYPTO_ALG_ASYNC);
}
noinline unsigned long __crypto_memneq(const void *a, const void *b, size_t size);
--
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit
2017-02-26 4:22 ` Herbert Xu
@ 2017-02-26 4:24 ` Herbert Xu
2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger
1 sibling, 0 replies; 13+ messages in thread
From: Herbert Xu @ 2017-02-26 4:24 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky
When we're used as a fallback algorithm, we should propagate
the NEED_FALLBACK bit when searching for the underlying ECB mode.
This just happens to fix a hang too because otherwise the search
may end up loading the same module that triggered this XTS creation.
Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/xts.c b/crypto/xts.c
index 410a2e2..baeb34d 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
struct xts_instance_ctx *ctx;
struct skcipher_alg *alg;
const char *cipher_name;
+ u32 mask;
int err;
algt = crypto_get_attr_type(tb);
@@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
ctx = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+
+ mask = crypto_requires_off(algt->type, algt->mask,
+ CRYPTO_ALG_NEED_FALLBACK |
+ CRYPTO_ALG_ASYNC);
+
+ err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask);
if (err == -ENOENT) {
err = -ENAMETOOLONG;
if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)",
cipher_name) >= CRYPTO_MAX_ALG_NAME)
goto err_free_inst;
- err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask);
}
if (err)
--
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup
2017-02-26 4:22 ` Herbert Xu
2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu
@ 2017-02-26 19:14 ` Harald Freudenberger
1 sibling, 0 replies; 13+ messages in thread
From: Harald Freudenberger @ 2017-02-26 19:14 UTC (permalink / raw)
To: Herbert Xu, Marcelo Cerri; +Cc: linux-crypto, Martin Schwidefsky
On 02/26/2017 05:22 AM, Herbert Xu wrote:
> On Sat, Feb 25, 2017 at 04:20:22PM -0300, Marcelo Cerri wrote:
>> Yeah, I agree. This should work as long as the module aliases are
>> correct, which is enough.
>>
>> Other templates will not trigger the same error since they don't have to
>> try more than one underlying algorithm. But I think this is still
>> desirable for the remaining templates to avoid a long chain of unused
>> fallbacks as in the example I gave in my previous email.
>>
>> Probably a helper function to return the correct mask might be useful
>> for readability and to avoid duplicate code.
> You're right. Here is a patch to add a helper for this.
> Thanks!
>
> ---8<---
> Subject: crypto: api - Add crypto_requires_off helper
>
> This patch adds crypto_requires_off which is an extension of
> crypto_requires_sync for similar bits such as NEED_FALLBACK.
>
> Suggested-by: Marcelo Cerri <marcelo.cerri@canonical.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
> index ebe4ded..436c4c2 100644
> --- a/include/crypto/algapi.h
> +++ b/include/crypto/algapi.h
> @@ -360,13 +360,18 @@ static inline struct crypto_alg *crypto_get_attr_alg(struct rtattr **tb,
> return crypto_attr_alg(tb[1], type, mask);
> }
>
> +static inline int crypto_requires_off(u32 type, u32 mask, u32 off)
> +{
> + return (type ^ off) & mask & off;
> +}
> +
> /*
> * Returns CRYPTO_ALG_ASYNC if type/mask requires the use of sync algorithms.
> * Otherwise returns zero.
> */
> static inline int crypto_requires_sync(u32 type, u32 mask)
> {
> - return (type ^ CRYPTO_ALG_ASYNC) & mask & CRYPTO_ALG_ASYNC;
> + return crypto_requires_off(type, mask, CRYPTO_ALG_ASYNC);
> }
>
> noinline unsigned long __crypto_memneq(const void *a, const void *b, size_t size);
applied the xts.c create patch v2 and the helper patch, built and installed.
Now the aes_s390 module loads perfect without any hang, no complains
in syslog and /proc/crypto shows that all selftests for the algs in the module
passed successful.
Thanks all for your help :-)
regards, Harald Freudenberger
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-02-26 19:14 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-17 17:50 crypto: hang in crypto_larval_lookup Harald Freudenberger
2017-02-23 11:19 ` Herbert Xu
2017-02-23 11:39 ` Herbert Xu
2017-02-23 16:02 ` Harald Freudenberger
2017-02-24 8:42 ` Harald Freudenberger
2017-02-24 10:32 ` Harald Freudenberger
2017-02-24 11:21 ` Harald Freudenberger
2017-02-24 23:44 ` Marcelo Cerri
2017-02-25 15:17 ` Herbert Xu
2017-02-25 19:20 ` Marcelo Cerri
2017-02-26 4:22 ` Herbert Xu
2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu
2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).