1. 05 12月, 2013 1 次提交
  2. 28 11月, 2013 3 次提交
    • H
      crypto: talitos - fix aead sglen for case 'dst != src' · 62293a37
      Horia Geanta 提交于
      For aead case when source and destination buffers are different,
      there is an incorrect assumption that the source length includes the ICV
      length. Fix this, since it leads to an oops when using sg_count() to
      find the number of nents in the scatterlist:
      
      Unable to handle kernel paging request for data at address 0x00000004
      Faulting instruction address: 0xf2265a28
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=8 P2020 RDB
      Modules linked in: talitos(+)
      CPU: 1 PID: 2187 Comm: cryptomgr_test Not tainted 3.11.0 #12
      task: c4e72e20 ti: ef634000 task.ti: ef634000
      NIP: f2265a28 LR: f2266ad8 CTR: c000c900
      REGS: ef635bb0 TRAP: 0300   Not tainted  (3.11.0)
      MSR: 00029000 <CE,EE,ME>  CR: 42042084  XER: 00000000
      DEAR: 00000004, ESR: 00000000
      
      GPR00: f2266e10 ef635c60 c4e72e20 00000001 00000014 ef635c69 00000001 c11f3082
      GPR08: 00000010 00000000 00000002 2f635d58 22044084 00000000 00000000 c0755c80
      GPR16: c4bf1000 ef784000 00000000 00000000 00000020 00000014 00000010 ef2f6100
      GPR24: ef2f6200 00000024 ef143210 ef2f6000 00000000 ef635d58 00000000 2f635d58
      NIP [f2265a28] sg_count+0x1c/0xb4 [talitos]
      LR [f2266ad8] talitos_edesc_alloc+0x12c/0x410 [talitos]
      Call Trace:
      [ef635c60] [c0552068] schedule_timeout+0x148/0x1ac (unreliable)
      [ef635cc0] [f2266e10] aead_edesc_alloc+0x54/0x64 [talitos]
      [ef635ce0] [f22680f0] aead_encrypt+0x24/0x70 [talitos]
      [ef635cf0] [c024b948] __test_aead+0x494/0xf68
      [ef635e20] [c024d54c] test_aead+0x64/0xcc
      [ef635e40] [c024d604] alg_test_aead+0x50/0xc4
      [ef635e60] [c024c838] alg_test+0x10c/0x2e4
      [ef635ee0] [c0249d1c] cryptomgr_test+0x4c/0x54
      [ef635ef0] [c005d598] kthread+0xa8/0xac
      [ef635f40] [c000e3bc] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      81230024 552807fe 0f080000 5523003a 4bffff24 39000000 2c040000 99050000
      408100a0 7c691b78 38c00001 38600000 <80e90004> 38630001 8109000c 70ea0002
      ---[ end trace 4498123cd8478591 ]---
      Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      62293a37
    • H
      crypto: caam - fix aead sglen for case 'dst != src' · bbf9c893
      Horia Geanta 提交于
      For aead case when source and destination buffers are different,
      there is an incorrect assumption that the source length includes the ICV
      length. Fix this, since it leads to an oops when using sg_count() to
      find the number of nents in the scatterlist:
      
      Unable to handle kernel paging request for data at address 0x00000004
      Faulting instruction address: 0xf91f7634
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=8 P4080 DS
      Modules linked in: caamalg(+) caam_jr caam
      CPU: 1 PID: 1053 Comm: cryptomgr_test Not tainted 3.11.0 #16
      task: eeb24ab0 ti: eeafa000 task.ti: eeafa000
      NIP: f91f7634 LR: f91f7f24 CTR: f91f7ef0
      REGS: eeafbbc0 TRAP: 0300   Not tainted  (3.11.0)
      MSR: 00029002 <CE,EE,ME>  CR: 44044044  XER: 00000000
      DEAR: 00000004, ESR: 00000000
      
      GPR00: f91f7f24 eeafbc70 eeb24ab0 00000002 ee8e0900 ee8e0800 00000024 c45c4462
      GPR08: 00000010 00000000 00000014 0c0e4000 24044044 00000000 00000000 c0691590
      GPR16: eeab0000 eeb23000 00000000 00000000 00000000 00000001 00000001 eeafbcc8
      GPR24: 000000d1 00000010 ee2d5000 ee49ea10 ee49ea10 ee46f640 ee46f640 c0691590
      NIP [f91f7634] aead_edesc_alloc.constprop.14+0x144/0x780 [caamalg]
      LR [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
      Call Trace:
      [eeafbc70] [a1004000] 0xa1004000 (unreliable)
      [eeafbcc0] [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
      [eeafbcf0] [c020d77c] __test_aead+0x3ec/0xe20
      [eeafbe20] [c020f35c] test_aead+0x6c/0xe0
      [eeafbe40] [c020f420] alg_test_aead+0x50/0xd0
      [eeafbe60] [c020e5e4] alg_test+0x114/0x2e0
      [eeafbee0] [c020bd1c] cryptomgr_test+0x4c/0x60
      [eeafbef0] [c0047058] kthread+0xa8/0xb0
      [eeafbf40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      69084321 7d080034 5508d97e 69080001 0f080000 81290024 552807fe 0f080000
      3a600001 5529003a 2f8a0000 40dd0028 <80e90004> 3ab50001 8109000c 70e30002
      ---[ end trace b3c3e23925c7484e ]---
      
      While here, add a tcrypt mode for making it easy to test authenc
      (needed for triggering case above).
      Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bbf9c893
    • H
      crypto: talitos - corrrectly handle zero-length assoc data · 935e99a3
      Horia Geanta 提交于
      talitos does not handle well zero-length assoc data. From dmesg:
      talitos ffe30000.crypto: master data transfer error
      talitos ffe30000.crypto: gather return/length error
      
      Check whether assoc data is provided by inspecting assoclen,
      not assoc pointer.
      This is needed in order to pass testmgr tests.
      Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      935e99a3
  3. 26 11月, 2013 1 次提交
  4. 22 11月, 2013 3 次提交
  5. 21 11月, 2013 32 次提交