1. 04 12月, 2015 6 次提交
    • L
      crypto: vmx - IV size failing on skcipher API · 0d3d054b
      Leonidas Da Silva Barbosa 提交于
      IV size was zero on CBC and CTR modes,
      causing a bug triggered by skcipher.
      
      Fixing this  adding a correct size.
      Signed-off-by: NLeonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
      Signed-off-by: NPaulo Smorigo <pfsmorigo@linux.vnet.ibm.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d3d054b
    • F
      crypto: caam - pass the correct buffer length · f456cd2d
      Fabio Estevam 提交于
      When buffer 0 is used we should use buflen_0 instead of buflen_1.
      
      Fix it.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f456cd2d
    • W
      crypto: cryptd - Assign statesize properly · 1a078340
      Wang, Rui Y 提交于
      cryptd_create_hash() fails by returning -EINVAL.  It is because after
      8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash
      drivers must have a non-zero statesize.
      
      This patch fixes the problem by properly assigning the statesize.
      Signed-off-by: NRui Wang <rui.y.wang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1a078340
    • W
      crypto: ghash-clmulni - Fix load failure · 3a020a72
      Wang, Rui Y 提交于
      ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
      "modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"
      
      After 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash
      drivers are required to implement import()/export(), and must have a non-
      zero statesize.
      
      This patch has been tested with the algif_hash interface. The calculated
      digest values, after several rounds of import()s and export()s, match those
      calculated by tcrypt.
      Signed-off-by: NRui Wang <rui.y.wang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3a020a72
    • H
      crypto: rockchip - fix possible deadlock · ac7c8e6b
      Heiko Stuebner 提交于
      Lockdep warns about a possible deadlock resulting from the use of regular
      spin_locks:
      
      =================================
      [ INFO: inconsistent lock state ]
      4.4.0-rc2+ #2724 Not tainted
      ---------------------------------
      inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
      (&(&crypto_info->lock)->rlock){+.?...}, at: [<bf14a65c>] rk_crypto_tasklet_cb+0x24/0xb4 [rk_crypto]
      {SOFTIRQ-ON-W} state was registered at:
        [<c007f4ac>] lock_acquire+0x178/0x218
        [<c0759bac>] _raw_spin_lock+0x54/0x64
        [<bf14af88>] rk_handle_req+0x7c/0xbc [rk_crypto]
        [<bf14b040>] rk_des_ecb_encrypt+0x2c/0x30 [rk_crypto]
        [<bf14b05c>] rk_aes_ecb_encrypt+0x18/0x1c [rk_crypto]
        [<c028c820>] skcipher_encrypt_ablkcipher+0x64/0x68
        [<c0290770>] __test_skcipher+0x2a8/0x8dc
        [<c0292e94>] test_skcipher+0x38/0xc4
        [<c0292fb0>] alg_test_skcipher+0x90/0xb0
        [<c0292158>] alg_test+0x1e8/0x280
        [<c028f6f4>] cryptomgr_test+0x34/0x54
        [<c004bbe8>] kthread+0xf4/0x10c
        [<c0010010>] ret_from_fork+0x14/0x24
      irq event stamp: 10672
      hardirqs last  enabled at (10672): [<c002fac8>] tasklet_action+0x48/0x104
      hardirqs last disabled at (10671): [<c002faa0>] tasklet_action+0x20/0x104
      softirqs last  enabled at (10658): [<c002ef84>] __do_softirq+0x358/0x49c
      softirqs last disabled at (10669): [<c002f108>] run_ksoftirqd+0x40/0x80
      
      other info that might help us debug this:
      Possible unsafe locking scenario:
      
          CPU0
          ----
        lock(&(&crypto_info->lock)->rlock);
        <Interrupt>
          lock(&(&crypto_info->lock)->rlock);
      
       *** DEADLOCK ***
      
      Fix this by moving to irq-disabling spinlocks.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ac7c8e6b
    • J
      hwrng: core - sleep interruptible in read · 1ab87298
      Jiri Slaby 提交于
      hwrng kthread can be waiting via hwrng_fillfn for some data from a rng
      like virtio-rng:
      hwrng           D ffff880093e17798     0   382      2 0x00000000
      ...
      Call Trace:
       [<ffffffff817339c6>] wait_for_completion_killable+0x96/0x210
       [<ffffffffa00aa1b7>] virtio_read+0x57/0xf0 [virtio_rng]
       [<ffffffff814f4a35>] hwrng_fillfn+0x75/0x130
       [<ffffffff810aa243>] kthread+0xf3/0x110
      
      And when some user program tries to read the /dev node in this state,
      we get:
      rngd            D ffff880093e17798     0   762      1 0x00000004
      ...
      Call Trace:
       [<ffffffff817351ac>] mutex_lock_nested+0x15c/0x3e0
       [<ffffffff814f478e>] rng_dev_read+0x6e/0x240
       [<ffffffff81231958>] __vfs_read+0x28/0xe0
       [<ffffffff81232393>] vfs_read+0x83/0x130
      
      And this is indeed unkillable. So use mutex_lock_interruptible
      instead of mutex_lock in rng_dev_read and exit immediatelly when
      interrupted. And possibly return already read data, if any (as POSIX
      allows).
      
      v2: use ERESTARTSYS instead of EINTR
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: <linux-crypto@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1ab87298
  2. 27 11月, 2015 3 次提交
  3. 24 11月, 2015 3 次提交
  4. 23 11月, 2015 8 次提交
  5. 17 11月, 2015 19 次提交
  6. 16 11月, 2015 1 次提交