1. 26 1月, 2015 2 次提交
  2. 20 1月, 2015 3 次提交
  3. 14 1月, 2015 1 次提交
  4. 13 1月, 2015 1 次提交
  5. 05 1月, 2015 1 次提交
  6. 29 12月, 2014 2 次提交
    • S
      crypto: algif_rng - enable RNG interface compilation · 2f375538
      Stephan Mueller 提交于
      Enable compilation of the RNG AF_ALG support and provide a Kconfig
      option to compile the RNG AF_ALG support.
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2f375538
    • S
      crypto: algif_rng - add random number generator support · 5afdfd22
      Stephan Mueller 提交于
      This patch adds the random number generator support for AF_ALG.
      
      A random number generator's purpose is to generate data without
      requiring the caller to provide any data. Therefore, the AF_ALG
      interface handler for RNGs only implements a callback handler for
      recvmsg.
      
      The following parameters provided with a recvmsg are processed by the
      RNG callback handler:
      
      	* sock - to resolve the RNG context data structure accessing the
      	  RNG instance private to the socket
      
      	* len - this parameter allows userspace callers to specify how
      	  many random bytes the RNG shall produce and return. As the
      	  kernel context for the RNG allocates a buffer of 128 bytes to
      	  store random numbers before copying them to userspace, the len
      	  parameter is checked that it is not larger than 128. If a
      	  caller wants more random numbers, a new request for recvmsg
      	  shall be made.
      
      The size of 128 bytes is chose because of the following considerations:
      
      	* to increase the memory footprint of the kernel too much (note,
      	  that would be 128 bytes per open socket)
      
      	* 128 is divisible by any typical cryptographic block size an
      	  RNG may have
      
      	* A request for random numbers typically only shall supply small
      	  amount of data like for keys or IVs that should only require
      	  one invocation of the recvmsg function.
      
      Note, during instantiation of the RNG, the code checks whether the RNG
      implementation requires seeding. If so, the RNG is seeded with output
      from get_random_bytes.
      
      A fully working example using all aspects of the RNG interface is
      provided at http://www.chronox.de/libkcapi.htmlSigned-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5afdfd22
  7. 26 12月, 2014 1 次提交
  8. 24 12月, 2014 1 次提交
  9. 22 12月, 2014 9 次提交
  10. 11 12月, 2014 1 次提交
  11. 10 12月, 2014 1 次提交
    • A
      put iov_iter into msghdr · c0371da6
      Al Viro 提交于
      Note that the code _using_ ->msg_iter at that point will be very
      unhappy with anything other than unshifted iovec-backed iov_iter.
      We still need to convert users to proper primitives.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c0371da6
  12. 05 12月, 2014 2 次提交
  13. 02 12月, 2014 1 次提交
    • S
      crypto: algif_skcipher - initialize upon init request · f26b7b80
      Stephan Mueller 提交于
      When using the algif_skcipher, the following call sequence causess a
      re-initialization:
      
      1. sendmsg with ALG_SET_OP and iov == NULL, iovlen == 0 (i.e
      initializing the cipher, but not sending data)
      
      2. sendmsg with msg->msg-controllen == 0 and iov != NULL (using the initalized
      cipher handle by sending data)
      
      In step 2, the cipher operation type (encryption or decryption) is reset
      to always decryption, because the local variable of enc is put into
      ctx->enc as ctx->user is still zero.
      
      The same applies when all send data is processed and ctx->used falls to
      zero followed by user space to send new data.
      
      This patch changes the behavior to only reset the cipher operation type
      (and the IV) if such configuration request is received.
      Signed-off-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f26b7b80
  14. 01 12月, 2014 1 次提交
  15. 28 11月, 2014 1 次提交
  16. 27 11月, 2014 1 次提交
  17. 26 11月, 2014 3 次提交
  18. 25 11月, 2014 1 次提交
    • D
      crypto: algif - add and use sock_kzfree_s() instead of memzero_explicit() · 79e88659
      Daniel Borkmann 提交于
      Commit e1bd95bf ("crypto: algif - zeroize IV buffer") and
      2a6af25b ("crypto: algif - zeroize message digest buffer")
      added memzero_explicit() calls on buffers that are later on
      passed back to sock_kfree_s().
      
      This is a discussed follow-up that, instead, extends the sock
      API and adds sock_kzfree_s(), which internally uses kzfree()
      instead of kfree() for passing the buffers back to slab.
      
      Having sock_kzfree_s() allows to keep the changes more minimal
      by just having a drop-in replacement instead of adding
      memzero_explicit() calls everywhere before sock_kfree_s().
      
      In kzfree(), the compiler is not allowed to optimize the memset()
      away and thus there's no need for memzero_explicit(). Both,
      sock_kfree_s() and sock_kzfree_s() are wrappers for
      __sock_kfree_s() and call into kfree() resp. kzfree(); here,
      __sock_kfree_s() needs to be explicitly inlined as we want the
      compiler to optimize the call and condition away and thus it
      produces e.g. on x86_64 the _same_ assembler output for
      sock_kfree_s() before and after, and thus also allows for
      avoiding code duplication.
      
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      79e88659
  19. 24 11月, 2014 4 次提交
  20. 12 11月, 2014 2 次提交
  21. 10 11月, 2014 1 次提交