1. 20 Jun, 2019 8 commits
  2. 13 Jun, 2019 17 commits
  3. 06 Jun, 2019 15 commits
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - fix atomic sleep when using async algorithm · 7545b6c2
      Eric Biggers authored
      Clear the CRYPTO_TFM_REQ_MAY_SLEEP flag when the chacha20poly1305
      operation is being continued from an async completion callback, since
      sleeping may not be allowed in that context.
      
      This is basically the same bug that was recently fixed in the xts and
      lrw templates.  But, it's always been broken in chacha20poly1305 too.
      This was found using syzkaller in combination with the updated crypto
      self-tests which actually test the MAY_SLEEP flag now.
      
      Reproducer:
      
          python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(
          	       ("aead", "rfc7539(cryptd(chacha20-generic),poly1305-generic)"))'
      
      Kernel output:
      
          BUG: sleeping function called from invalid context at include/crypto/algapi.h:426
          in_atomic(): 1, irqs_disabled(): 0, pid: 1001, name: kworker/2:2
          [...]
          CPU: 2 PID: 1001 Comm: kworker/2:2 Not tainted 5.2.0-rc2 #5
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
          Workqueue: crypto cryptd_queue_worker
          Call Trace:
           __dump_stack lib/dump_stack.c:77 [inline]
           dump_stack+0x4d/0x6a lib/dump_stack.c:113
           ___might_sleep kernel/sched/core.c:6138 [inline]
           ___might_sleep.cold.19+0x8e/0x9f kernel/sched/core.c:6095
           crypto_yield include/crypto/algapi.h:426 [inline]
           crypto_hash_walk_done+0xd6/0x100 crypto/ahash.c:113
           shash_ahash_update+0x41/0x60 crypto/shash.c:251
           shash_async_update+0xd/0x10 crypto/shash.c:260
           crypto_ahash_update include/crypto/hash.h:539 [inline]
           poly_setkey+0xf6/0x130 crypto/chacha20poly1305.c:337
           poly_init+0x51/0x60 crypto/chacha20poly1305.c:364
           async_done_continue crypto/chacha20poly1305.c:78 [inline]
           poly_genkey_done+0x15/0x30 crypto/chacha20poly1305.c:369
           cryptd_skcipher_complete+0x29/0x70 crypto/cryptd.c:279
           cryptd_skcipher_decrypt+0xcd/0x110 crypto/cryptd.c:339
           cryptd_queue_worker+0x70/0xa0 crypto/cryptd.c:184
           process_one_work+0x1ed/0x420 kernel/workqueue.c:2269
           worker_thread+0x3e/0x3a0 kernel/workqueue.c:2415
           kthread+0x11f/0x140 kernel/kthread.c:255
           ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      Fixes: 71ebc4d1 ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
      Cc: <stable@vger.kernel.org> # v4.2+
      Cc: Martin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7545b6c2
    • YueHaibing's avatar
      crypto: atmel-i2c - Fix build error while CRC16 set to m · 4bb02dbd
      YueHaibing authored
      If CRYPTO_DEV_ATMEL_ECC is set m, which select CRC16 to m,
      while CRYPTO_DEV_ATMEL_SHA204A is set to y, building fails.
      
      drivers/crypto/atmel-i2c.o: In function 'atmel_i2c_checksum':
      atmel-i2c.c:(.text+0x16): undefined reference to 'crc16'
      
      Add CRC16 dependency to CRYPTO_DEV_ATMEL_SHA204A
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: da001fb6 ("crypto: atmel-i2c - add support for SHA204A random number generator")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4bb02dbd
    • Iuliana Prodan's avatar
      crypto: caam - disable some clock checks for iMX7ULP · 385cfc84
      Iuliana Prodan authored
      Disabled the check and set of 'mem' and 'emi_slow'
      clocks, since these are not available for iMX7ULP.
      Signed-off-by: default avatarIuliana Prodan <iuliana.prodan@nxp.com>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      385cfc84
    • Ard Biesheuvel's avatar
      crypto: caam - limit output IV to CBC to work around CTR mode DMA issue · ed527b13
      Ard Biesheuvel authored
      The CAAM driver currently violates an undocumented and slightly
      controversial requirement imposed by the crypto stack that a buffer
      referred to by the request structure via its virtual address may not
      be modified while any scatterlists passed via the same request
      structure are mapped for inbound DMA.
      
      This may result in errors like
      
        alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74
        alg: aead: Failed to load transform for gcm(aes): -2
      
      on non-cache coherent systems, due to the fact that the GCM driver
      passes an IV buffer by virtual address which shares a cacheline with
      the auth_tag buffer passed via a scatterlist, resulting in corruption
      of the auth_tag when the IV is updated while the DMA mapping is live.
      
      Since the IV that is returned to the caller is only valid for CBC mode,
      and given that the in-kernel users of CBC (such as CTS) don't trigger the
      same issue as the GCM driver, let's just disable the output IV generation
      for all modes except CBC for the time being.
      
      Fixes: 854b06f7 ("crypto: caam - properly set IV after {en,de}crypt")
      Cc: Horia Geanta <horia.geanta@nxp.com>
      Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
      Reported-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarHoria Geanta <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ed527b13
    • Herbert Xu's avatar
      crypto: atmel - Fix sparse endianness warnings · 49d22167
      Herbert Xu authored
      The param2 member in atmel_i2c_cmd is supposed to be little-endian
      but was marked as u16.  This patch changes it to a __le16 which
      reveals a missing endian swap in atmel_i2c_init_read_cmd.
      
      Another missing little-endian marking is also added in
      atmel_i2c_checksum.
      
      Fixes: 11105693 ("crypto: atmel-ecc - introduce Microchip...")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      49d22167
    • Eric Biggers's avatar
      crypto: lrw - use correct alignmask · 20a0f976
      Eric Biggers authored
      Commit c778f96b ("crypto: lrw - Optimize tweak computation")
      incorrectly reduced the alignmask of LRW instances from
      '__alignof__(u64) - 1' to '__alignof__(__be32) - 1'.
      
      However, xor_tweak() and setkey() assume that the data and key,
      respectively, are aligned to 'be128', which has u64 alignment.
      
      Fix the alignmask to be at least '__alignof__(be128) - 1'.
      
      Fixes: c778f96b ("crypto: lrw - Optimize tweak computation")
      Cc: <stable@vger.kernel.org> # v4.20+
      Cc: Ondrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      20a0f976
    • Eric Biggers's avatar
      crypto: ghash - fix unaligned memory access in ghash_setkey() · 5c6bc4df
      Eric Biggers authored
      Changing ghash_mod_init() to be subsys_initcall made it start running
      before the alignment fault handler has been installed on ARM.  In kernel
      builds where the keys in the ghash test vectors happened to be
      misaligned in the kernel image, this exposed the longstanding bug that
      ghash_setkey() is incorrectly casting the key buffer (which can have any
      alignment) to be128 for passing to gf128mul_init_4k_lle().
      
      Fix this by memcpy()ing the key to a temporary buffer.
      
      Don't fix it by setting an alignmask on the algorithm instead because
      that would unnecessarily force alignment of the data too.
      
      Fixes: 2cdc6899 ("crypto: ghash - Add GHASH digest algorithm for GCM")
      Reported-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Tested-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5c6bc4df
    • Nikolay Borisov's avatar
      crypto: xxhash - Implement xxhash support · 67882e76
      Nikolay Borisov authored
      xxhash is currently implemented as a self-contained module in /lib.
      This patch enables that module to be used as part of the generic kernel
      crypto framework. It adds a simple wrapper to the 64bit version.
      
      I've also added test vectors (with help from Nick Terrell). The upstream
      xxhash code is tested by running hashing operation on random 222 byte
      data with seed values of 0 and a prime number. The upstream test
      suite can be found at https://github.com/Cyan4973/xxHash/blob/cf46e0c/xxhsum.c#L664
      
      Essentially hashing is run on data of length 0,1,14,222 with the
      aforementioned seed values 0 and prime 2654435761. The particular random
      222 byte string was provided to me by Nick Terrell by reading
      /dev/random and the checksums were calculated by the upstream xxsum
      utility with the following bash script:
      
      dd if=/dev/random of=TEST_VECTOR bs=1 count=222
      
      for a in 0 1; do
      	for l in 0 1 14 222; do
      		for s in 0 2654435761; do
      			echo algo $a length $l seed $s;
      			head -c $l TEST_VECTOR | ~/projects/kernel/xxHash/xxhsum -H$a -s$s
      		done
      	done
      done
      
      This produces output as follows:
      
      algo 0 length 0 seed 0
      02cc5d05  stdin
      algo 0 length 0 seed 2654435761
      02cc5d05  stdin
      algo 0 length 1 seed 0
      25201171  stdin
      algo 0 length 1 seed 2654435761
      25201171  stdin
      algo 0 length 14 seed 0
      c1d95975  stdin
      algo 0 length 14 seed 2654435761
      c1d95975  stdin
      algo 0 length 222 seed 0
      b38662a6  stdin
      algo 0 length 222 seed 2654435761
      b38662a6  stdin
      algo 1 length 0 seed 0
      ef46db3751d8e999  stdin
      algo 1 length 0 seed 2654435761
      ac75fda2929b17ef  stdin
      algo 1 length 1 seed 0
      27c3f04c2881203a  stdin
      algo 1 length 1 seed 2654435761
      4a15ed26415dfe4d  stdin
      algo 1 length 14 seed 0
      3d33dc700231dfad  stdin
      algo 1 length 14 seed 2654435761
      ea5f7ddef9a64f80  stdin
      algo 1 length 222 seed 0
      5f3d3c08ec2bef34  stdin
      algo 1 length 222 seed 2654435761
      6a9df59664c7ed62  stdin
      
      algo 1 is xx64 variant, algo 0 is the 32 bit variant which is currently
      not hooked up.
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarEric Biggers <ebiggers@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      67882e76
    • Stephan Müller's avatar
      crypto: jitter - update implementation to 2.1.2 · d9d67c87
      Stephan Müller authored
      The Jitter RNG implementation is updated to comply with upstream version
      2.1.2. The change covers the following aspects:
      
      * Time variation measurement is conducted over the LFSR operation
      instead of the XOR folding
      
      * Invcation of stuck test during initialization
      
      * Removal of the stirring functionality and the Von-Neumann
      unbiaser as the LFSR using a primitive and irreducible polynomial
      generates an identical distribution of random bits
      
      This implementation was successfully used in FIPS 140-2 validations
      as well as in German BSI evaluations.
      
      This kernel implementation was tested as follows:
      
      * The unchanged kernel code file jitterentropy.c is compiled as part
      of user space application to generate raw unconditioned noise
      data. That data is processed with the NIST SP800-90B non-IID test
      tool to verify that the kernel code exhibits an equal amount of noise
      as the upstream Jitter RNG version 2.1.2.
      
      * Using AF_ALG with the libkcapi tool of kcapi-rng the Jitter RNG was
      output tested with dieharder to verify that the output does not
      exhibit statistical weaknesses. The following command was used:
      kcapi-rng -n "jitterentropy_rng" -b 100000000000 | dieharder -a -g 200
      
      * The unchanged kernel code file jitterentropy.c is compiled as part
      of user space application to test the LFSR implementation. The
      LFSR is injected a monotonically increasing counter as input and
      the output is fed into dieharder to verify that the LFSR operation
      does not exhibit statistical weaknesses.
      
      * The patch was tested on the Muen separation kernel which returns
      a more coarse time stamp to verify that the Jitter RNG does not cause
      regressions with its initialization test considering that the Jitter
      RNG depends on a high-resolution timer.
      Tested-by: default avatarReto Buerki <reet@codelabs.ch>
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d9d67c87
    • Eric Biggers's avatar
      crypto: testmgr - test the shash API · d8ea98aa
      Eric Biggers authored
      For hash algorithms implemented using the "shash" algorithm type, test
      both the ahash and shash APIs, not just the ahash API.
      
      Testing the ahash API already tests the shash API indirectly, which is
      normally good enough.  However, there have been corner cases where there
      have been shash bugs that don't get exposed through the ahash API.  So,
      update testmgr to test the shash API too.
      
      This would have detected the arm64 SHA-1 and SHA-2 bugs for which fixes
      were just sent out (https://patchwork.kernel.org/patch/10964843/ and
      https://patchwork.kernel.org/patch/10965089/):
      
          alg: shash: sha1-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer"
          alg: shash: sha224-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer"
          alg: shash: sha256-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer"
      
      This also would have detected the bugs fixed by commit 307508d1
      ("crypto: crct10dif-generic - fix use via crypto_shash_digest()") and
      commit dec3d0b1
      ("crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest()").
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d8ea98aa
    • Elena Petrova's avatar
      crypto: arm64/sha2-ce - correct digest for empty data in finup · 6bd934de
      Elena Petrova authored
      The sha256-ce finup implementation for ARM64 produces wrong digest
      for empty input (len=0). Expected: the actual digest, result: initial
      value of SHA internal state. The error is in sha256_ce_finup:
      for empty data `finalize` will be 1, so the code is relying on
      sha2_ce_transform to make the final round. However, in
      sha256_base_do_update, the block function will not be called when
      len == 0.
      
      Fix it by setting finalize to 0 if data is empty.
      
      Fixes: 03802f6a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarElena Petrova <lenaptr@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6bd934de
    • Elena Petrova's avatar
      crypto: arm64/sha1-ce - correct digest for empty data in finup · 1d4aaf16
      Elena Petrova authored
      The sha1-ce finup implementation for ARM64 produces wrong digest
      for empty input (len=0). Expected: da39a3ee..., result: 67452301...
      (initial value of SHA internal state). The error is in sha1_ce_finup:
      for empty data `finalize` will be 1, so the code is relying on
      sha1_ce_transform to make the final round. However, in
      sha1_base_do_update, the block function will not be called when
      len == 0.
      
      Fix it by setting finalize to 0 if data is empty.
      
      Fixes: 07eb54d3 ("crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarElena Petrova <lenaptr@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1d4aaf16
    • Iuliana Prodan's avatar
      crypto: caam - strip input without changing crypto request · 3b2614cb
      Iuliana Prodan authored
      For rsa and pkcs1pad, CAAM expects an input of modulus size.
      For this we strip the leading zeros in case the size is more than modulus.
      This commit avoids modifying the crypto request while stripping zeros from
      input, to comply with the crypto API requirement. This is done by adding
      a fixup input pointer and length.
      Signed-off-by: default avatarIuliana Prodan <iuliana.prodan@nxp.com>
      Reviewed-by: default avatarHoria Geanta <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3b2614cb
    • Iuliana Prodan's avatar
      crypto: caam - fix pkcs1pad(rsa-caam, sha256) failure because of invalid input · c3725f7c
      Iuliana Prodan authored
      The problem is with the input data size sent to CAAM for encrypt/decrypt.
      Pkcs1pad is failing due to pkcs1 padding done in SW starting with0x01
      instead of 0x00 0x01.
      CAAM expects an input of modulus size. For this we strip the leading
      zeros in case the size is more than modulus or pad the input with zeros
      until the modulus size is reached.
      Signed-off-by: default avatarIuliana Prodan <iuliana.prodan@nxp.com>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c3725f7c
    • Antoine Tenart's avatar
      crypto: inside-secure - do not rely on the hardware last bit for result descriptors · 89332590
      Antoine Tenart authored
      When performing a transformation the hardware is given result
      descriptors to save the result data. Those result descriptors are
      batched using a 'first' and a 'last' bit. There are cases were more
      descriptors than needed are given to the engine, leading to the engine
      only using some of them, and not setting the last bit on the last
      descriptor we gave. This causes issues were the driver and the hardware
      aren't in sync anymore about the number of result descriptors given (as
      the driver do not give a pool of descriptor to use for any
      transformation, but a pool of descriptors to use *per* transformation).
      
      This patch fixes it by attaching the number of given result descriptors
      to the requests, and by using this number instead of the 'last' bit
      found on the descriptors to process them.
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      89332590