1. 18 Apr, 2019 29 commits
  2. 16 Apr, 2019 1 commit
  3. 15 Apr, 2019 2 commits
  4. 08 Apr, 2019 8 commits
    • Eric Biggers's avatar
      crypto: testmgr - add panic_on_fail module parameter · eda69b0c
      Eric Biggers authored
      Add a module parameter cryptomgr.panic_on_fail which causes the kernel
      to panic if any crypto self-tests fail.
      
      Use cases:
      
      - More easily detect crypto self-test failures by boot testing,
        e.g. on KernelCI.
      - Get a bug report if syzkaller manages to use the template system to
        instantiate an algorithm that fails its self-tests.
      
      The command-line option "fips=1" already does this, but it also makes
      other changes not wanted for general testing, such as disabling
      "unapproved" algorithms.  panic_on_fail just does what it says.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      eda69b0c
    • Eric Biggers's avatar
      crypto: arm64/cbcmac - handle empty messages in same way as template · f6e9af87
      Eric Biggers authored
      My patches to make testmgr fuzz algorithms against their generic
      implementation detected that the arm64 implementations of "cbcmac(aes)"
      handle empty messages differently from the cbcmac template.  Namely, the
      arm64 implementations return the encrypted initial value, but the cbcmac
      template returns the initial value directly.
      
      This isn't actually a meaningful case because any user of cbcmac needs
      to prepend the message length, as CCM does; otherwise it's insecure.
      However, we should keep the behavior consistent; at the very least this
      makes testing easier.
      
      Do it the easy way, which is to change the arm64 implementations to have
      the same behavior as the cbcmac template.
      
      For what it's worth, ghash does things essentially the same way: it
      returns its initial value when given an empty message, even though in
      practice ghash is never passed an empty message.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f6e9af87
    • Eric Biggers's avatar
      crypto: cts - don't support empty messages · c31a8719
      Eric Biggers authored
      My patches to make testmgr fuzz algorithms against their generic
      implementation detected that the arm64 implementations of
      "cts(cbc(aes))" handle empty messages differently from the cts template.
      Namely, the arm64 implementations forbids (with -EINVAL) all messages
      shorter than the block size, including the empty message; but the cts
      template permits empty messages as a special case.
      
      No user should be CTS-encrypting/decrypting empty messages, but we need
      to keep the behavior consistent.  Unfortunately, as noted in the source
      of OpenSSL's CTS implementation [1], there's no common specification for
      CTS.  This makes it somewhat debatable what the behavior should be.
      
      However, all CTS specifications seem to agree that messages shorter than
      the block size are not allowed, and OpenSSL follows this in both CTS
      conventions it implements.  It would also simplify the user-visible
      semantics to have empty messages no longer be a special case.
      
      Therefore, make the cts template return -EINVAL on *all* messages
      shorter than the block size, including the empty message.
      
      [1] https://github.com/openssl/openssl/blob/master/crypto/modes/cts128.cSigned-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c31a8719
    • Eric Biggers's avatar
      crypto: streebog - fix unaligned memory accesses · c5c46887
      Eric Biggers authored
      Don't cast the data buffer directly to streebog_uint512, as this
      violates alignment rules.
      
      Fixes: fe18957e ("crypto: streebog - add Streebog hash function")
      Cc: Vitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c5c46887
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - set cra_name correctly · 5e27f38f
      Eric Biggers authored
      If the rfc7539 template is instantiated with specific implementations,
      e.g. "rfc7539(chacha20-generic,poly1305-generic)" rather than
      "rfc7539(chacha20,poly1305)", then the implementation names end up
      included in the instance's cra_name.  This is incorrect because it then
      prevents all users from allocating "rfc7539(chacha20,poly1305)", if the
      highest priority implementations of chacha20 and poly1305 were selected.
      Also, the self-tests aren't run on an instance allocated in this way.
      
      Fix it by setting the instance's cra_name from the underlying
      algorithms' actual cra_names, rather than from the requested names.
      This matches what other templates do.
      
      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>
      Reviewed-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5e27f38f
    • Eric Biggers's avatar
      crypto: skcipher - don't WARN on unprocessed data after slow walk step · dcaca01a
      Eric Biggers authored
      skcipher_walk_done() assumes it's a bug if, after the "slow" path is
      executed where the next chunk of data is processed via a bounce buffer,
      the algorithm says it didn't process all bytes.  Thus it WARNs on this.
      
      However, this can happen legitimately when the message needs to be
      evenly divisible into "blocks" but isn't, and the algorithm has a
      'walksize' greater than the block size.  For example, ecb-aes-neonbs
      sets 'walksize' to 128 bytes and only supports messages evenly divisible
      into 16-byte blocks.  If, say, 17 message bytes remain but they straddle
      scatterlist elements, the skcipher_walk code will take the "slow" path
      and pass the algorithm all 17 bytes in the bounce buffer.  But the
      algorithm will only be able to process 16 bytes, triggering the WARN.
      
      Fix this by just removing the WARN_ON().  Returning -EINVAL, as the code
      already does, is the right behavior.
      
      This bug was detected by my patches that improve testmgr to fuzz
      algorithms against their generic implementation.
      
      Fixes: b286d8b1 ("crypto: skcipher - Add skcipher walk interface")
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      dcaca01a
    • Eric Biggers's avatar
      crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest() · dec3d0b1
      Eric Biggers authored
      The ->digest() method of crct10dif-pclmul reads the current CRC value
      from the shash_desc context.  But this value is uninitialized, causing
      crypto_shash_digest() to compute the wrong result.  Fix it.
      
      Probably this wasn't noticed before because lib/crc-t10dif.c only uses
      crypto_shash_update(), not crypto_shash_digest().  Likewise,
      crypto_shash_digest() is not yet tested by the crypto self-tests because
      those only test the ahash API which only uses shash init/update/final.
      
      Fixes: 0b95a7f8 ("crypto: crct10dif - Glue code to cast accelerated CRCT10DIF assembly as a crypto transform")
      Cc: <stable@vger.kernel.org> # v3.11+
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      dec3d0b1
    • Eric Biggers's avatar
      crypto: crct10dif-generic - fix use via crypto_shash_digest() · 307508d1
      Eric Biggers authored
      The ->digest() method of crct10dif-generic reads the current CRC value
      from the shash_desc context.  But this value is uninitialized, causing
      crypto_shash_digest() to compute the wrong result.  Fix it.
      
      Probably this wasn't noticed before because lib/crc-t10dif.c only uses
      crypto_shash_update(), not crypto_shash_digest().  Likewise,
      crypto_shash_digest() is not yet tested by the crypto self-tests because
      those only test the ahash API which only uses shash init/update/final.
      
      This bug was detected by my patches that improve testmgr to fuzz
      algorithms against their generic implementation.
      
      Fixes: 2d31e518 ("crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework")
      Cc: <stable@vger.kernel.org> # v3.11+
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      307508d1