1
0
Fork 0
Commit Graph

3 Commits (3ca7bf8756a0426e642446ae35df31a29a1b1108)

Author SHA1 Message Date
Ying Xue 1b78414047 net: Remove iocb argument from sendmsg and recvmsg
After TIPC doesn't depend on iocb argument in its internal
implementations of sendmsg() and recvmsg() hooks defined in proto
structure, no any user is using iocb argument in them at all now.
Then we can drop the redundant iocb argument completely from kinds of
implementations of both sendmsg() and recvmsg() in the entire
networking stack.

Cc: Christoph Hellwig <hch@lst.de>
Suggested-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-02 13:06:31 -05:00
Wei Yongjun 598de36952 crypto: algif_rng - fix sparse non static symbol warning
Fixes the following sparse warnings:

crypto/algif_rng.c:185:13: warning:
 symbol 'rng_exit' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Stephan Mueller <smueller@chronox.de>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-01-14 21:57:57 +11:00
Stephan Mueller 5afdfd22e6 crypto: algif_rng - add random number generator support
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.html

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-12-29 21:37:59 +11:00