Skip to content
Snippets Groups Projects
  1. Mar 10, 2010
  2. Jul 14, 2009
  3. Jul 13, 2009
  4. Jul 08, 2009
  5. Jun 18, 2009
  6. Jun 01, 2009
    • Herbert Xu's avatar
      crypto: testmgr - Dynamically allocate xbuf and axbuf · f8b0d4d0
      Herbert Xu authored
      
      We currently allocate temporary memory that is used for testing
      statically.  This renders the testing engine non-reentrant. As
      algorithms may nest, i.e., one may construct another in order to
      carry out a part of its operation, this is unacceptable.  For
      example, it has been reported that an AEAD implementation allocates
      a cipher in its setkey function, which causes it to fail during
      testing as the temporary memory is overwritten.
      
      This patch replaces the static memory with dynamically allocated
      buffers.  We need a maximum of 16 pages so this slightly increases
      the chances of an algorithm failing due to memory shortage.
      However, as testing usually occurs at registration, this shouldn't
      be a big problem.
      
      Reported-by: default avatarShasi Pulijala <spulijala@amcc.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f8b0d4d0
  7. Feb 18, 2009
    • Herbert Xu's avatar
      crypto: api - Fix crypto_alloc_tfm/create_create_tfm return convention · 3f683d61
      Herbert Xu authored
      
      This is based on a report and patch by Geert Uytterhoeven.
      
      The functions crypto_alloc_tfm and create_create_tfm return a
      pointer that needs to be adjusted by the caller when successful
      and otherwise an error value.  This means that the caller has
      to check for the error and only perform the adjustment if the
      pointer returned is valid.
      
      Since all callers want to make the adjustment and we know how
      to adjust it ourselves, it's much easier to just return adjusted
      pointer directly.
      
      The only caveat is that we have to return a void * instead of
      struct crypto_tfm *.  However, this isn't that bad because both
      of these functions are for internal use only (by types code like
      shash.c, not even algorithms code).
      
      This patch also moves crypto_alloc_tfm into crypto/internal.h
      (crypto_create_tfm is already there) to reflect this.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3f683d61
  8. Dec 24, 2008
    • Herbert Xu's avatar
      crypto: api - Rebirth of crypto_alloc_tfm · 7b0bac64
      Herbert Xu authored
      
      This patch reintroduces a completely revamped crypto_alloc_tfm.
      The biggest change is that we now take two crypto_type objects
      when allocating a tfm, a frontend and a backend.  In fact this
      simply formalises what we've been doing behind the API's back.
      
      For example, as it stands crypto_alloc_ahash may use an
      actual ahash algorithm or a crypto_hash algorithm.  Putting
      this in the API allows us to do this much more cleanly.
      
      The existing types will be converted across gradually.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7b0bac64
  9. Aug 28, 2008
  10. Jul 10, 2008
  11. Jan 10, 2008
    • Herbert Xu's avatar
      [CRYPTO] skcipher: Create default givcipher instances · b9c55aa4
      Herbert Xu authored
      
      This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always
      return algorithms that are capable of generating their own IVs through
      givencrypt and givdecrypt.  Each algorithm may specify its default IV
      generator through the geniv field.
      
      For algorithms that do not set the geniv field, the blkcipher layer will
      pick a default.  Currently it's chainiv for synchronous algorithms and
      eseqiv for asynchronous algorithms.  Note that if these wrappers do not
      work on an algorithm then that algorithm must specify its own geniv or
      it can't be used at all.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b9c55aa4
    • Herbert Xu's avatar
      [CRYPTO] scatterwalk: Move scatterwalk.h to linux/crypto · 42c271c6
      Herbert Xu authored
      
      The scatterwalk infrastructure is used by algorithms so it needs to
      move out of crypto for future users that may live in drivers/crypto
      or asm/*/crypto.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      42c271c6
  12. Oct 10, 2007
    • Herbert Xu's avatar
      [CRYPTO] api: Kill crypto_km_types · 70dec235
      Herbert Xu authored
      
      When scatterwalk is built as a module digest.c was broken because it
      requires the crypto_km_types structure which is in scatterwalk.  This
      patch removes the crypto_km_types structure by encoding the logic into
      crypto_kmap_type directly.
      
      In fact, this even saves a few bytes of code (not to mention the data
      structure itself) on i386 which is about the only place where it's
      needed.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      70dec235
  13. Feb 06, 2007
  14. Sep 20, 2006
  15. Jan 09, 2006
    • Herbert Xu's avatar
      [CRYPTO] Allow multiple implementations of the same algorithm · 5cb1454b
      Herbert Xu authored
      
      This is the first step on the road towards asynchronous support in
      the Crypto API.  It adds support for having multiple crypto_alg objects
      for the same algorithm registered in the system.
      
      For example, each device driver would register a crypto_alg object
      for each algorithm that it supports.  While at the same time the
      user may load software implementations of those same algorithms.
      
      Users of the Crypto API may then select a specific implementation
      by name, or choose any implementation for a given algorithm with
      the highest priority.
      
      The priority field is a 32-bit signed integer.  In future it will be
      possible to modify it from user-space.
      
      This also provides a solution to the problem of selecting amongst
      various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5cb1454b
  16. Sep 01, 2005
    • Herbert Xu's avatar
      [CRYPTO]: Added CRYPTO_TFM_REQ_MAY_SLEEP flag · 64baf3cf
      Herbert Xu authored
      
      The crypto layer currently uses in_atomic() to determine whether it is
      allowed to sleep.  This is incorrect since spin locks don't always cause
      in_atomic() to return true.
      
      Instead of that, this patch returns to an earlier idea of a per-tfm flag
      which determines whether sleeping is allowed.  Unlike the earlier version,
      the default is to not allow sleeping.  This ensures that no existing code
      can break.
      
      As usual, this flag may either be set through crypto_alloc_tfm(), or
      just before a specific crypto operation.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64baf3cf
  17. Jul 15, 2005
  18. Jul 06, 2005
  19. May 23, 2005
    • Herbert Xu's avatar
      [CRYPTO]: Only reschedule if !in_atomic() · 15333038
      Herbert Xu authored
      
      The netlink gfp_any() problem made me double-check the uses of in_softirq()
      in crypto/*.  It seems to me that we should be checking in_atomic() instead
      of in_softirq() in crypto_yield.  Otherwise people calling the crypto ops
      with spin locks held or preemption disabled will get burnt, right?
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15333038
  20. Apr 16, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
Loading