Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Stephan Mueller
Am Sonntag, 27. April 2014, 20:19:41 schrieb Theodore Ts'o: Hi Theodore, On Sun, Apr 27, 2014 at 08:49:48PM +0200, Stephan Mueller wrote: With the heavy update of random.c during the 3.13 development, the re-seeding of the nonblocking_pool from the input_pool is now prevented for a

Re: [RFC PATCH v2 4/9] crypto: qce: Add ablkcipher algorithms

2014-04-28 Thread Herbert Xu
On Mon, Apr 14, 2014 at 03:48:40PM +0300, Stanimir Varbanov wrote: + if (IS_AES(flags)) { + switch (keylen) { + case AES_KEYSIZE_128: + case AES_KEYSIZE_256: + break; + default: + goto badkey; You

Re: [RFC PATCH v2 4/9] crypto: qce: Add ablkcipher algorithms

2014-04-28 Thread Herbert Xu
On Mon, Apr 14, 2014 at 03:48:40PM +0300, Stanimir Varbanov wrote: + } else if (IS_DES(flags)) { + u32 tmp[DES_EXPKEY_WORDS]; + + if (keylen != QCE_DES_KEY_SIZE) + goto badkey; No need to check here since you've already set min_keysize and

Re: [RFC PATCH v2 1/9] crypto: qce: Add core driver implementation

2014-04-28 Thread Herbert Xu
On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote: + if (backlog) + backlog-complete(backlog, -EINPROGRESS); The completion function needs to be called with BH disabled. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page:

Re: [RFC PATCH v2 1/9] crypto: qce: Add core driver implementation

2014-04-28 Thread Herbert Xu
On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote: +#define QCE_MAJOR_VERSION5 0x05 +#define QCE_QUEUE_LENGTH 50 What is the purpose of this software queue? Why can't you directly feed the requests to the hardware? If the hardware can't handle more than 50 requests

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Herbert Xu
On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote: GFP_ATOMIC memory allocation could fail. In this case, avoid NULL pointer dereference and notify user. Cc: sta...@vger.kernel.org # 3.2+ Cc: Kim Phillips kim.phill...@freescale.com Signed-off-by: Horia Geanta

Re: [PATCH 0/2] crypto: atmel-aes: fixes on block size of aes cfb mode

2014-04-28 Thread Herbert Xu
On Tue, Apr 22, 2014 at 03:23:22PM +0800, Leilei Zhao wrote: Hi: These two patches correct the block size in atmel-aes driver while processing cfb8 and cfb64 mode of aes. Both patches applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page:

Re: [PATCH 0/3] Cleanup ressource leaks in test_aead_speed()

2014-04-28 Thread Herbert Xu
On Mon, Apr 21, 2014 at 08:44:39PM +0200, Christian Engelmayer wrote: This is a cleanup of Coverity ressource leak findings for the quick dirty crypto testing module crypto/tcrypt.c. All 3 changesets address function test_aead_speed() that was introduced in 53f52d7a (crypto: tcrypt - Added

[PATCH 6/7 v8] crypto:s5p-sss: Use clk_prepare/clk_unprepare

2014-04-28 Thread Naveen Krishna Chatradhi
This patch set adds use of clk_prepare/clk_unprepare as required by generic clock framework. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Acked-by: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC:

[PATCH 4/7 v8] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver

2014-04-28 Thread Naveen Krishna Chatradhi
This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Acked-by: Herbert Xu

[PATCH 5/7 v8] crypto:s5p-sss: validate iv before memcpy

2014-04-28 Thread Naveen Krishna Chatradhi
This patch adds code to validate iv buffer before trying to memcpy the contents Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Acked-by: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC: Vladimir Zapolskiy

[PATCH 7/7 v8] crypto:s5p-sss: Look for the next request in the queue

2014-04-28 Thread Naveen Krishna Chatradhi
Currently, the driver enqueues a request only if the busy bit is false. And every request initiates a dequeue. If 2 requests arrive simultaneously, only one of them will be dequeued. To avoid this senario, we will enqueue the next request irrespective of the system condition (that is what queue

[PATCH 3/7 v8] crypto:s5p-sss: Add support for SSS module on Exynos

2014-04-28 Thread Naveen Krishna Chatradhi
This patch adds new compatible and variant struct to support the SSS module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250) for which 1. AES register are at an offset of 0x200 and 2. hash interrupt is not available Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

[PATCH 2/7 v8] crypto:s5p-sss: Add device tree support

2014-04-28 Thread Naveen Krishna Chatradhi
This patch adds device tree support to the s5p-sss.c crypto driver. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Acked-by: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC: Vladimir Zapolskiy vzapols...@gmail.com TO: linux-crypto@vger.kernel.org

[PATCH 1/7 v8] crypto:s5p-sss: Use platform_get_irq() instead of _byname()

2014-04-28 Thread Naveen Krishna Chatradhi
This patch uses the platform_get_irq() instead of the platform_get_irq_byname(). Making feeder control interrupt as resource 0 and hash interrupt as 1. reasons for this change. 1. Cannot find any Arch which is currently using this driver 2. Samsung Exynos4 and 5 SoCs only use the feeder control

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Theodore Ts'o
On Mon, Apr 28, 2014 at 08:00:19AM +0200, Stephan Mueller wrote: However, given that we're reseeding once a minute (or as needed), it's actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a DRBG is forbidden to reseed itself automatically). To be honest, I do not read that in

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Stephan Mueller
Am Montag, 28. April 2014, 10:23:50 schrieb Theodore Ts'o: Hi Theodore, I am not too convinced of RDRAND due to the lack of usable source code (i.e. source code that I can build myself). But that is my personal taste :-) The problem is the FIPS validation would presumably require obeying

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Gregory Baudet
3. An approved DRBG, thus forming a chain of at least two DRBGs; the initial DRBG in the chain SHALL be seeded by an approved NRBG or an approved entropy source. A DRBG instantiation may seed or reseed another DRBG instantiation, but SHALL NOT reseed itself.

Re: [PATCH] crypto: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN

2014-04-28 Thread Marek Vasut
On Friday, April 25, 2014 at 12:51:06 AM, Matthias-Christian Ott wrote: CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most information provided by CRYPTO_MSG_GETALG is also accessible through /proc/modules and AF_ALG. CRYPTO_MSG_GETALG should not require CAP_NET_ADMIN so that

Re: [PATCH] staging: crypto: skein: depend upon CRYPTO

2014-04-28 Thread Marek Vasut
On Friday, April 25, 2014 at 06:45:09 PM, Jason Cooper wrote: Fengguang's randconfig kernel build tester discovered the following warnings: warning: (CRYPTO_THREEFISH) selects CRYPTO_ALGAPI which has unmet direct dependencies (CRYPTO) warning: (DM_VERITY CRYPTO_SKEIN) selects CRYPTO_HASH

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Marek Vasut
On Monday, April 28, 2014 at 12:24:41 PM, Herbert Xu wrote: On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote: GFP_ATOMIC memory allocation could fail. In this case, avoid NULL pointer dereference and notify user. Cc: sta...@vger.kernel.org # 3.2+ Cc: Kim Phillips

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Marek Vasut
On Monday, April 28, 2014 at 11:53:23 PM, Herbert Xu wrote: On Mon, Apr 28, 2014 at 09:28:41PM +0200, Marek Vasut wrote: On Monday, April 28, 2014 at 12:24:41 PM, Herbert Xu wrote: On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote: GFP_ATOMIC memory allocation could fail.