1. 30 May, 2019 25 commits
  2. 23 May, 2019 15 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
    • Stephan Mueller's avatar
      crypto: drbg - add FIPS 140-2 CTRNG for noise source · db07cd26
      Stephan Mueller authored
      FIPS 140-2 section 4.9.2 requires a continuous self test of the noise
      source. Up to kernel 4.8 drivers/char/random.c provided this continuous
      self test. Afterwards it was moved to a location that is inconsistent
      with the FIPS 140-2 requirements. The relevant patch was
      e192be9d .
      
      Thus, the FIPS 140-2 CTRNG is added to the DRBG when it obtains the
      seed. This patch resurrects the function drbg_fips_continous_test that
      existed some time ago and applies it to the noise sources. The patch
      that removed the drbg_fips_continous_test was
      b3614763 .
      
      The Jitter RNG implements its own FIPS 140-2 self test and thus does not
      need to be subjected to the test in the DRBG.
      
      The patch contains a tiny fix to ensure proper zeroization in case of an
      error during the Jitter RNG data gathering.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Reviewed-by: default avatarYann Droneaud <ydroneaud@opteya.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      db07cd26
    • Horia Geantă's avatar
      crypto: caam/qi - DMA map keys using proper device · a7cd942b
      Horia Geantă authored
      Currently there is a mismatch b/w the ICID (Isolation Context ID) used
      for DMA mapping keys and ICID used for accessing them.
      -keys are DMA mapped using a job ring device, thus a job ring ICID
      -keys are accessed from descriptors enqueued via Queue Interface,
      thus using QI ICID
      
      [Note: ICIDs of JRs, QI are configured by U-boot / other entity by:
      -fixing up the corresponding job ring and controller DT nodes
      -setting up corresponding caam ICID registers]
      
      In order to avoid IOMMU faults, DMA map the key using the controller
      device instead of a job ring device.
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a7cd942b
    • Horia Geantă's avatar
      crypto: caam/qi - fix address translations with IOMMU enabled · b2b2ee35
      Horia Geantă authored
      When IOMMU is enabled, iova -> phys address translation should be
      performed using iommu_ops, not dma_to_phys().
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b2b2ee35
    • Horia Geantă's avatar
      crypto: caam/qi - don't allocate an extra platform device · 6b175685
      Horia Geantă authored
      Use the controller device for caam/qi instead of allocating
      a new platform device.
      This is needed as a preparation to add support for working behind an
      SMMU. A platform device allocated using platform_device_register_full()
      is not completely set up - most importantly .dma_configure()
      is not called.
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6b175685
    • Horia Geantă's avatar
      crypto: caam - convert top level drivers to libraries · 1b46c90c
      Horia Geantă authored
      Currently we allow top level code, i.e. that which sits between the
      low level (HW-specific) drivers and crypto API, to be built as several
      drivers: caamalg, caamhash, caam_pkc, caamrng, caamalg_qi.
      
      There is no advantage in this, more it interferes with adding support
      for deferred probing (there are no corresponding devices and thus
      no bus).
      
      Convert these drivers and call init() / exit() manually at the right
      time.
      Move algorithms initialization at JR probe / remove time:
      -the first probed JR registers the crypto algs
      -the last removed JR unregisters the crypto algs
      
      Note: caam_qi_init() is called before JR platform devices creation
      (of_populate_bus()), such that QI interface is initialized when
      the caam/qi algorithms are registered in the JR driver (by calling
      caam_qi_algapi_init().
      
      While here, fix the Kconfig entries under CRYPTO_DEV_FSL_CAAM_JR
      to be aligned.
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1b46c90c
    • Horia Geantă's avatar
      crypto: caam - fix S/G table passing page boundary · a5e5c133
      Horia Geantă authored
      According to CAAM RM:
      -crypto engine reads 4 S/G entries (64 bytes) at a time,
      even if the S/G table has fewer entries
      -it's the responsibility of the user / programmer to make sure
      this HW behaviour has no side effect
      
      The drivers do not take care of this currently, leading to IOMMU faults
      when the S/G table ends close to a page boundary - since only one page
      is DMA mapped, while CAAM's DMA engine accesses two pages.
      
      Fix this by rounding up the number of allocated S/G table entries
      to a multiple of 4.
      Note that in case of two *contiguous* S/G tables, only the last table
      might needs extra entries.
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a5e5c133