1. 16 Nov, 2012 1 commit
    • Terry Lv's avatar
      ENGR00233800: CAAM: running sha_speed in cryptodev crashed · 0346ca03
      Terry Lv authored
      The reason is that when switching from SHA1 to SHA256, cryptodev will
      create a new session.
      But in this new session, the __ctx in allocated req is not fully initialized.
      Thus dma_buf in __ctx will be a random value.
      If the value is 0 or some address in DMA memory, that will be ok,
      otherwise, it will crashed in dma_unmap_single().
      The calling sequence is:
      ahash_final_ctx=>try_buf_map_to_sec_sg()=>dma_unmap_single()
      When calling dma_unmap_single(), the parameter buf_dma is invalid in
      crash case.
      The error msg is:
      kernel BUG at arch/arm/mm/dma-mapping.c:478!
      
      requested hash CRYPTO_SHA2_256, Unable to handle kernel NULL pointer
      dereference at virtual address 00000000
      got sha256 with driver sha256-caapgd = e4ea0000
      m
              Encrypting in chunks of 256 b[00000000] *pgd=74edb831ytes: ,
      	*pte=00000000, *ppte=00000000
      	Internal error: Oops: 817 [#1] PREEMPT SMP
      	Modules linked in: cryptodev
      	CPU: 0    Not tainted  (3.0.35-02200-ge392070a-dirty #68)
           PC is at __bug+0x1c/0x28
           LR is at __bug+0x18/0x28
           pc : [<80044260>]    lr : [<8004425c>]    psr: 60000013
           sp : e4ec7c40  ip : ea9a2000  fp : 00000010
           r10: 883f8038  r9 : 883f8038  r8 : e4803060
           r7 : 00000000  r6 : 00000001  r5 : 00000000  r4 : 6f66c10a
           r3 : 00000000  r2 : 80aafd5c  r1 : 60000093  r0 : 00000033
           Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
           Control: 10c53c7d  Table: 74ea004a  DAC: 00000015
           Process sha_speed (pid: 2747, stack limit = 0xe4ec62f0)
           Stack: (0xe4ec7c40 to 0xe4ec8000)
           7c40: 74803184 8004a424 e4803000 e4730c08 e4262840 803c50dc
           e4786f20 883f8000
           7c60: 00000020 00000000 00000028 883f8018 e43ffcc0 e4803000
           00000000 803c3d04
           7c80: 00000004 80041104 e4ec6000 00000000 7efc4b64 803c3d10
           e4774a3c 802079f8
           7ca0: e43ffd1c e43ffcc0 00000000 7f0031a0 e4ec7e0c e43ffcc0
           e4ec7e0c 7f00240c
           7cc0: 00000100 e4786f20 e481bd40 e4ec7cd8 e4ec7cdc 7f0016b4
           e4803200 00000000
           7ce0: e4094480 00000000 7efc4b2c 00000004 80041104 7f001b64
           8c81200c 00000000
           7d00: 3fe1c2a2 2aba7e2c 00000000 00000000 00000000 00000000
           00000000 2abc8870
           7d20: 2abc8870 2abc8870 7efc4e10 00000000 2aba3000 00000000
           2abc7f48 00000000
           7d40: 00000000 00000000 00000000 00000000 00000000 00000000
           2abc7f88 2abc7f80
           7d60: 2abc7f50 2abc7f60 2abc7f68 00000000 00000000 00000000
           2abc7f70 2abc7f78
           7d80: 00000000 32616873 2a003635 00000000 00000000 2abc7fa0
           2abc7fa8 2abc7fb0
           7da0: 2abc7f90 00000000 00000000 2abc7f98 00000000 00000000
           00000000 00000000
           7dc0: 00000000 32616873 632d3635 006d6161 00000000 00000000
           00000000 00000000
           7de0: 2abc7fc0 2abc7fb8 00000000 2abc7fd0 00000000 00000000
           00000000 00000000
           7e00: 00000000 00000000 00000001 3fe1c2a2 00000000 00000100
           00012008 00000000
           7e20: 7efc4ab8 00000000 00000000 8006a120 e4044740 8c80ef40
           00000001 00000000
           7e40: 00000002 e4044740 e4ec7e7c 8006f5f4 e4ec6000 8007ffd4
           e4348880 60000093
           7e60: 00000000 80ae6de8 e4253200 8004e0fc 00000261 8028c0f4
           e4877000 80ae6de8
           7e80: e4786f20 e481bd40 00000261 8028c0f4 000059ac 00000000
           36390b02 00000000
           7ea0: e4cd7b6c e43488d0 8c80e4c4 00000038 e43488d0 802342dc
           0000003f e43488d0
           7ec0: 8c80e4b8 8c80e4b8 00000038 80090714 0000003f 8aafab02
           00000000 80091134
           7ee0: 8aafab02 0000003f e4ec6000 80a99cc0 e4eed510 7efc4b2c
           e4ef96e0 00000004
           7f00: 80041104 800febd0 60a9b3cd e4786f20 e4348880 00000000
           e4ec7f88 e43488d0
           7f20: e4ec6000 00000000 00000000 80091408 00000000 00000001
           00000001 e4ec7f78
           7f40: 000059b1 00000000 fffffff7 80aedc50 80a8a0c0 00000000
           00000000 e4ec7f90
           7f60: 7efc4b20 e4ef96e0 7efc4b2c c01c6368 00000004 80041104
           e4ec6000 00000000
           7f80: 7efc4b64 800ff0d4 00000000 00000000 00000109 00000000
           00000000 00008628
           7fa0: 00000036 80040f80 00000000 00000000 00000004 c01c6368
           7efc4b2c 7efc4b2c
           7fc0: 00000000 00000000 00008628 00000036 00000000 00000000
           2abc8000 7efc4b64
           7fe0: 00000000 7efc4a90 00008b5c 2ac857bc 80000010 00000004
           e28bd000 e8bd0800
           [<80044260>] (__bug+0x1c/0x28) from [<8004a424>]
           (___dma_single_dev_to_cpu+0x84/0x94)
           [<8004a424>] (___dma_single_dev_to_cpu+0x84/0x94) from [<803c50dc>]
           (ahash_final_ctx+0x1a0/0x41c)
           [<803c50dc>] (ahash_final_ctx+0x1a0/0x41c) from [<803c3d10>]
           (ahash_final+0xc/0x10)
           [<803c3d10>] (ahash_final+0xc/0x10) from [<802079f8>]
           (crypto_ahash_op+0x28/0xc0)
           [<802079f8>] (crypto_ahash_op+0x28/0xc0) from [<7f0031a0>]
           (cryptodev_hash_final+0x30/0xc0 [cryptodev])
           [<7f0031a0>] (cryptodev_hash_final+0x30/0xc0 [cryptodev]) from
           [<7f00240c>] (crypto_run+0x10c/0x398 [cryptodev])
           [<7f00240c>] (crypto_run+0x10c/0x398 [cryptodev]) from [<7f001b64>]
           (cryptodev_ioctl+0x360/0x768 [cryptodev])
           [<7f001b64>] (cryptodev_ioctl+0x360/0x768 [cryptodev]) from
           [<800febd0>] (do_vfs_ioctl+0x80/0x54c)
           [<800febd0>] (do_vfs_ioctl+0x80/0x54c) from [<800ff0d4>]
           (sys_ioctl+0x38/0x5c)
           [<800ff0d4>] (sys_ioctl+0x38/0x5c) from [<80040f80>]
           (ret_fast_syscall+0x0/0x30)
           Code: e59f0010 e1a01003 eb12fddb e3a03000 (e5833000)
           ---[ end trace 0057f6be00952f77 ]---
      Signed-off-by: default avatarTerry Lv <r65388@freescale.com>
      0346ca03
  2. 03 Sep, 2012 2 commits
    • Steve Cornelius's avatar
      ENGR00215875-2: caam: fix descriptor buffer overrun in hash_digest_key() · c2fabda1
      Steve Cornelius authored
      HMAC keys often need to be reduced to under the size of a digest to
      be used. The driver does this psuedo-synchronously through the use of
      hash_digest_key(), which builds a sequence pointered job descriptor to
      perform this function.
      
      When this function built the job descriptor, it correctly accounted for the
      number of instructions and number of pointers that would go into its
      construction. However, it failed to account for the fact that both the
      sequence in and out pointers used extended lengths, adding 8 more bytes to
      the required job descriptor. This caused the descriptor to overrun the
      allocated buffer by that amount, resulting in memory corruptions.
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarTerry Lv <r65388@freescale.com>
      c2fabda1
    • Steve Cornelius's avatar
      ENGR00215875-1: caam: improve initalization for context state saves · aa151237
      Steve Cornelius authored
      Multiple function in asynchronous hashing use a saved-state block,
      a.k.a. struct caam_hash_state, which holds a stash of information
      between requests (init/update/final). Certain values in this state
      block are loaded for processing using an inline-if, and when this
      is done, the potential for uninitialized data can pose conflicts.
      Therefore, this patch improves initialization of state data to
      prevent false assignments using uninitialized data in the state block.
      
      This patch addresses the following traceback, originating in
      ahash_final_ctx(), although a problem like this could certainly
      exhibit other symptoms:
      
      kernel BUG at arch/arm/mm/dma-mapping.c:465!
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = 80004000
      [00000000] *pgd=00000000
      Internal error: Oops: 805 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
      PC is at __bug+0x1c/0x28
      LR is at __bug+0x18/0x28
      pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
      sp : e423fd98  ip : 60000013  fp : 0000001c
      r10: e4191b84  r9 : 00000020  r8 : 00000009
      r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
      r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c53c7d  Table: 1000404a  DAC: 00000015
      Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
      Stack: (0xe423fd98 to 0xe4240000)
      fd80:                                                       11807fd1 80048544
      fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
      fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
      fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
      fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
      fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
      fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
      fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
      fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
      fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
      fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
      ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
      ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
      ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
      ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
      ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
      ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
      ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
      ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
      [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
      [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
      [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
      [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
      [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
      [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
      [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
      [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
      [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
      [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
      Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
      ---[ end trace d52a403a1d1eaa86 ]---
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarTerry Lv <r65388@freescale.com>
      aa151237
  3. 25 Jul, 2012 2 commits
    • Steve Cornelius's avatar
      ENGR00215945-2: Fix directions in cache coherence functions · e4bdc0bf
      Steve Cornelius authored
      During a bug search, a review turned up two places where the wrong
      direction was used in dma_sync function calls. In practice. these
      compiled away to be inconsequential on the platform in question, but
      this may not be true on all platforms.
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarTerry Lv <r65388@freescale.com>
      e4bdc0bf
    • Steve Cornelius's avatar
      ENGR00215945-1: Rework scatterlist handling for bi-endian platforms · 631a53a1
      Steve Cornelius authored
      Former versions of this (ARM) branch of this driver reworked the hardware-
      readable scatter/gather list to operate as a set of 32-bit integers,
      rather than a packed structure of smaller sizes, which cannot burst-read
      correctly on a little-endian platform.
      
      Integration of caamhash.c revealed subtle ways in which the ordering of
      items written to a hardware s/g list could create bugs, such as the
      "final" bit being written to an entry that would later be updated with
      a size, inadvertently erasing the bit (e.g. such as sg_to_sec4_sg_last()
      before sg_to_sec4_sg()).
      
      Since fields must be ORed in to operate correctly using any order of
      operations, changed allocations of the combination of extended descriptor
      structs + hardware scatterlists to use kzalloc() instead of kmalloc(), so
      as to ensure that residue data would not be ORed in with the correct data.
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarTerry Lv <r65388@freescale.com>
      631a53a1
  4. 20 Jul, 2012 3 commits