1. 04 2月, 2015 1 次提交
    • A
      crypto: switch af_alg_make_sg() to iov_iter · 1d10eb2f
      Al Viro 提交于
      With that, all ->sendmsg() instances are converted to iov_iter primitives
      and are agnostic wrt the kind of iov_iter they are working with.
      So's the last remaining ->recvmsg() instance that wasn't kind-agnostic yet.
      All ->sendmsg() and ->recvmsg() advance ->msg_iter by the amount actually
      copied and none of them modifies the underlying iovec, etc.
      
      Cc: linux-crypto@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1d10eb2f
  2. 05 12月, 2014 1 次提交
  3. 17 11月, 2014 1 次提交
  4. 13 11月, 2014 4 次提交
  5. 14 10月, 2014 1 次提交
    • B
      crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code · a0a77af1
      Behan Webster 提交于
      Add a macro which replaces the use of a Variable Length Array In Struct (VLAIS)
      with a C99 compliant equivalent. This macro instead allocates the appropriate
      amount of memory using an char array.
      
      The new code can be compiled with both gcc and clang.
      
      struct shash_desc contains a flexible array member member ctx declared with
      CRYPTO_MINALIGN_ATTR, so sizeof(struct shash_desc) aligns the beginning
      of the array declared after struct shash_desc with long long.
      
      No trailing padding is required because it is not a struct type that can
      be used in an array.
      
      The CRYPTO_MINALIGN_ATTR is required so that desc is aligned with long long
      as would be the case for a struct containing a member with
      CRYPTO_MINALIGN_ATTR.
      
      If you want to get to the ctx at the end of the shash_desc as before you can do
      so using shash_desc_ctx(shash)
      Signed-off-by: NBehan Webster <behanw@converseincode.com>
      Reviewed-by: NMark Charlebois <charlebm@gmail.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Cc: Michał Mirosław <mirqus@gmail.com>
      a0a77af1
  6. 06 10月, 2014 1 次提交
  7. 17 9月, 2014 1 次提交
    • D
      KEYS: Overhaul key identification when searching for asymmetric keys · 46963b77
      David Howells 提交于
      Make use of the new match string preparsing to overhaul key identification
      when searching for asymmetric keys.  The following changes are made:
      
       (1) Use the previously created asymmetric_key_id struct to hold the following
           key IDs derived from the X.509 certificate or PKCS#7 message:
      
      	id: serial number + issuer
      	skid: subjKeyId + subject
      	authority: authKeyId + issuer
      
       (2) Replace the hex fingerprint attached to key->type_data[1] with an
           asymmetric_key_ids struct containing the id and the skid (if present).
      
       (3) Make the asymmetric_type match data preparse select one of two searches:
      
           (a) An iterative search for the key ID given if prefixed with "id:".  The
           	 prefix is expected to be followed by a hex string giving the ID to
           	 search for.  The criterion key ID is checked against all key IDs
           	 recorded on the key.
      
           (b) A direct search if the key ID is not prefixed with "id:".  This will
           	 look for an exact match on the key description.
      
       (4) Make x509_request_asymmetric_key() take a key ID.  This is then converted
           into "id:<hex>" and passed into keyring_search() where match preparsing
           will turn it back into a binary ID.
      
       (5) X.509 certificate verification then takes the authority key ID and looks
           up a key that matches it to find the public key for the certificate
           signature.
      
       (6) PKCS#7 certificate verification then takes the id key ID and looks up a
           key that matches it to find the public key for the signed information
           block signature.
      
      Additional changes:
      
       (1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
           cert to be rejected with -EBADMSG.
      
       (2) The 'fingerprint' ID is gone.  This was primarily intended to convey PGP
           public key fingerprints.  If PGP is supported in future, this should
           generate a key ID that carries the fingerprint.
      
       (3) Th ca_keyid= kernel command line option is now converted to a key ID and
           used to match the authority key ID.  Possibly this should only match the
           actual authKeyId part and not the issuer as well.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NVivek Goyal <vgoyal@redhat.com>
      46963b77
  8. 05 9月, 2014 1 次提交
  9. 26 8月, 2014 1 次提交
  10. 25 8月, 2014 2 次提交
  11. 01 8月, 2014 1 次提交
  12. 29 7月, 2014 1 次提交
  13. 08 7月, 2014 4 次提交
  14. 04 7月, 2014 1 次提交
  15. 20 6月, 2014 4 次提交
    • J
      crypto: des_3des - add x86-64 assembly implementation · 6574e6c6
      Jussi Kivilinna 提交于
      Patch adds x86_64 assembly implementation of Triple DES EDE cipher algorithm.
      Two assembly implementations are provided. First is regular 'one-block at
      time' encrypt/decrypt function. Second is 'three-blocks at time' function that
      gains performance increase on out-of-order CPUs.
      
      tcrypt test results:
      
      Intel Core i5-4570:
      
      des3_ede-asm vs des3_ede-generic:
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
      16B     1.21x   1.22x   1.27x   1.36x   1.25x   1.25x
      64B     1.98x   1.96x   1.23x   2.04x   2.01x   2.00x
      256B    2.34x   2.37x   1.21x   2.40x   2.38x   2.39x
      1024B   2.50x   2.47x   1.22x   2.51x   2.52x   2.51x
      8192B   2.51x   2.53x   1.21x   2.56x   2.54x   2.55x
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@iki.fi>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6574e6c6
    • S
      crypto: drbg - header file for DRBG · 3e16f959
      Stephan Mueller 提交于
      The header file includes the definition of:
      
      * DRBG data structures with
              - struct drbg_state as main structure
              - struct drbg_core referencing the backend ciphers
              - struct drbg_state_ops callbach handlers for specific code
                supporting the Hash, HMAC, CTR DRBG implementations
              - struct drbg_conc defining a linked list for input data
              - struct drbg_test_data holding the test "entropy" data for CAVS
                testing and testmgr.c
              - struct drbg_gen allowing test data, additional information
                string and personalization string data to be funneled through
                the kernel crypto API -- the DRBG requires additional
                parameters when invoking the reset and random number
                generation requests than intended by the kernel crypto API
      
      * wrapper function to the kernel crypto API functions using struct
        drbg_gen to pass through all data needed for DRBG
      
      * wrapper functions to kernel crypto API functions usable for testing
        code to inject test_data into the DRBG as needed by CAVS testing and
        testmgr.c.
      
      * DRBG flags required for the operation of the DRBG and for selecting
        the particular DRBG type and backend cipher
      
      * getter functions for data from struct drbg_core
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3e16f959
    • M
      crypto: skcipher - Don't use __crypto_dequeue_request() · d656c180
      Marek Vasut 提交于
      Use skcipher_givcrypt_cast(crypto_dequeue_request(queue)) instead, which
      does the same thing in much cleaner way. The skcipher_givcrypt_cast()
      actually uses container_of() instead of messing around with offsetof()
      too.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d656c180
    • M
      crypto: api - Move crypto_yield() to algapi.h · bb55a4c1
      Marek Vasut 提交于
      It makes no sense for crypto_yield() to be defined in scatterwalk.h ,
      move it into algapi.h as it's an internal function to crypto API.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bb55a4c1
  16. 21 5月, 2014 1 次提交
    • H
      crypto: hash - Add real ahash walk interface · 75ecb231
      Herbert Xu 提交于
      Although the existing hash walk interface has already been used
      by a number of ahash crypto drivers, it turns out that none of
      them were really asynchronous.  They were all essentially polling
      for completion.
      
      That's why nobody has noticed until now that the walk interface
      couldn't work with a real asynchronous driver since the memory
      is mapped using kmap_atomic.
      
      As we now have a use-case for a real ahash implementation on x86,
      this patch creates a minimal ahash walk interface.  Basically it
      just calls kmap instead of kmap_atomic and does away with the
      crypto_yield call.  Real ahash crypto drivers don't need to yield
      since by definition they won't be hogging the CPU.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      75ecb231
  17. 21 3月, 2014 1 次提交
  18. 10 3月, 2014 2 次提交
  19. 09 12月, 2013 1 次提交
  20. 28 11月, 2013 1 次提交
    • T
      crypto: scatterwalk - Set the chain pointer indication bit · 41da8b5a
      Tom Lendacky 提交于
      The scatterwalk_crypto_chain function invokes the scatterwalk_sg_chain
      function to chain two scatterlists, but the chain pointer indication
      bit is not set.  When the resulting scatterlist is used, for example,
      by sg_nents to count the number of scatterlist entries, a segfault occurs
      because sg_nents does not follow the chain pointer to the chained scatterlist.
      
      Update scatterwalk_sg_chain to set the chain pointer indication bit as is
      done by the sg_chain function.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      41da8b5a
  21. 26 10月, 2013 2 次提交
  22. 16 10月, 2013 1 次提交
  23. 07 10月, 2013 1 次提交
    • J
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      James Yonan 提交于
      When comparing MAC hashes, AEAD authentication tags, or other hash
      values in the context of authentication or integrity checking, it
      is important not to leak timing information to a potential attacker,
      i.e. when communication happens over a network.
      
      Bytewise memory comparisons (such as memcmp) are usually optimized so
      that they return a nonzero value as soon as a mismatch is found. E.g,
      on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
      and up to ~850 cyc for a full match (cold). This early-return behavior
      can leak timing information as a side channel, allowing an attacker to
      iteratively guess the correct result.
      
      This patch adds a new method crypto_memneq ("memory not equal to each
      other") to the crypto API that compares memory areas of the same length
      in roughly "constant time" (cache misses could change the timing, but
      since they don't reveal information about the content of the strings
      being compared, they are effectively benign). Iow, best and worst case
      behaviour take the same amount of time to complete (in contrast to
      memcmp).
      
      Note that crypto_memneq (unlike memcmp) can only be used to test for
      equality or inequality, NOT for lexicographical order. This, however,
      is not an issue for its use-cases within the crypto API.
      
      We tried to locate all of the places in the crypto API where memcmp was
      being used for authentication or integrity checking, and convert them
      over to crypto_memneq.
      
      crypto_memneq is declared noinline, placed in its own source file,
      and compiled with optimizations that might increase code size disabled
      ("Os") because a smart compiler (or LTO) might notice that the return
      value is always compared against zero/nonzero, and might then
      reintroduce the same early-return optimization that we are trying to
      avoid.
      
      Using #pragma or __attribute__ optimization annotations of the code
      for disabling optimization was avoided as it seems to be considered
      broken or unmaintained for long time in GCC [1]. Therefore, we work
      around that by specifying the compile flag for memneq.o directly in
      the Makefile. We found that this seems to be most appropriate.
      
      As we use ("Os"), this patch also provides a loop-free "fast-path" for
      frequently used 16 byte digests. Similarly to kernel library string
      functions, leave an option for future even further optimized architecture
      specific assembler implementations.
      
      This was a joint work of James Yonan and Daniel Borkmann. Also thanks
      for feedback from Florian Weimer on this and earlier proposals [2].
      
        [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
        [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: NJames Yonan <james@openvpn.net>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
  24. 26 9月, 2013 2 次提交
  25. 25 9月, 2013 2 次提交
  26. 24 9月, 2013 1 次提交