1. 30 May, 2019 31 commits
  2. 23 May, 2019 9 commits
    • Christian Lamparter's avatar
      crypto: crypto4xx - block ciphers should only accept complete blocks · 0f7a8137
      Christian Lamparter authored
      The hardware automatically zero pads incomplete block ciphers
      blocks without raising any errors. This is a screw-up. This
      was noticed by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS tests that
      sent a incomplete blocks and expect them to fail.
      
      This fixes:
      cbc-aes-ppc4xx encryption unexpectedly succeeded on test vector
      "random: len=2409 klen=32"; expected_error=-22, cfg="random:
      may_sleep use_digest src_divs=[96.90%@+2295, 2.34%@+4066,
      0.32%@alignmask+12, 0.34%@+4087, 0.9%@alignmask+1787, 0.1%@+3767]
      iv_offset=6"
      
      ecb-aes-ppc4xx encryption unexpectedly succeeded on test vector
      "random: len=1011 klen=32"; expected_error=-22, cfg="random:
      may_sleep use_digest src_divs=[100.0%@alignmask+20]
      dst_divs=[3.12%@+3001, 96.88%@+4070]"
      
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1]
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0f7a8137
    • Christian Lamparter's avatar
      crypto: crypto4xx - fix blocksize for cfb and ofb · 70c4997f
      Christian Lamparter authored
      While the hardware consider them to be blockciphers, the
      reference implementation defines them as streamciphers.
      
      Do the right thing and set the blocksize to 1. This
      was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS.
      
      This fixes the following issues:
      skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1)
      skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1)
      
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      70c4997f
    • Christian Lamparter's avatar
      crypto: crypto4xx - fix AES CTR blocksize value · bfa2ba7d
      Christian Lamparter authored
      This patch fixes a issue with crypto4xx's ctr(aes) that was
      discovered by libcapi's kcapi-enc-test.sh test.
      
      The some of the ctr(aes) encryptions test were failing on the
      non-power-of-two test:
      
      kcapi-enc - Error: encryption failed with error 0
      kcapi-enc - Error: decryption failed with error 0
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits):
      original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855)
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
      (openssl generated CT): original file (e3b0..5) and generated file (3..8e)
      [PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
      (openssl generated PT)
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password):
      original file (1d1..84c) and generated file (e3b..852b855)
      
      But the 16, 32, 512, 65536 tests always worked.
      
      Thankfully, this isn't a hidden hardware problem like previously,
      instead this turned out to be a copy and paste issue.
      
      With this patch, all the tests are passing with and
      kcapi-enc-test.sh gives crypto4xx's a clean bill of health:
       "Number of failures: 0" :).
      
      Cc: stable@vger.kernel.org
      Fixes: 98e87e3d ("crypto: crypto4xx - add aes-ctr support")
      Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      bfa2ba7d
    • Sascha Hauer's avatar
      crypto: caam - print debugging hex dumps after unmapping · bb992bc4
      Sascha Hauer authored
      For encryption the destination pointer was still mapped, so the hex dump
      may be wrong. The IV still contained the input IV while printing instead
      of the output IV as intended.
      
      For decryption the destination pointer was still mapped, so the hex dump
      may be wrong. The IV dump was correct.
      
      Do the hex dumps consistenly after the buffers have been unmapped and
      in case of IV copied to their final destination.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      bb992bc4
    • Christophe Leroy's avatar
      crypto: talitos - fix skcipher failure due to wrong output IV · 3e03e792
      Christophe Leroy authored
      Selftests report the following:
      
      [    2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
      [    2.995377] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
      [    3.032673] alg: skcipher: cbc-des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
      [    3.043185] 00000000: fe dc ba 98 76 54 32 10
      [    3.063238] alg: skcipher: cbc-3des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
      [    3.073818] 00000000: 7d 33 88 93 0f 93 b2 42
      
      This above dumps show that the actual output IV is indeed the input IV.
      This is due to the IV not being copied back into the request.
      
      This patch fixes that.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3e03e792
    • Hook, Gary's avatar
      crypto: ccp - Fix 3DES complaint from ccp-crypto module · 89646fdd
      Hook, Gary authored
      Crypto self-tests reveal an error:
      
      alg: skcipher: cbc-des3-ccp encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
      
      The offset value should not be recomputed when retrieving the context.
      Also, a code path exists which makes decisions based on older (version 3)
      hardware; a v3 device deosn't support 3DES so remove this check.
      
      Fixes: 990672d4 ('crypto: ccp - Enable 3DES function on v5 CCPs')
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      89646fdd
    • Hook, Gary's avatar
      crypto: ccp - fix AES CFB error exposed by new test vectors · c3b359d6
      Hook, Gary authored
      Updated testmgr will exhibit this error message when loading the
      ccp-crypto module:
      
      alg: skcipher: cfb-aes-ccp encryption failed with err -22 on test vector 3, cfg="in-place"
      
      Update the CCP crypto driver to correctly treat CFB as a streaming mode
      cipher (instead of block mode). Update the configuration for CFB to
      specify the block size as a single byte;
      
      Fixes: 2b789435 ('crypto: ccp - CCP AES crypto API support')
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c3b359d6
    • Hook, Gary's avatar
      crypto: ccp - AES CFB mode is a stream cipher · 499df967
      Hook, Gary authored
      CFB mode should be treated as a stream cipher, not block.
      
      Fixes: 63b94509 ('crypto: ccp - CCP device driver and interface support')
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      499df967
    • YueHaibing's avatar
      crypto: arm/sha512 - Make sha512_arm_final static · efc77e81
      YueHaibing authored
      Fix sparse warning:
      
      arch/arm/crypto/sha512-glue.c:40:5: warning:
       symbol 'sha512_arm_final' was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      efc77e81