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 f

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

2014-04-28 Thread Herbert Xu
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. > > > In this case, avoid NULL pointer dereference and notify u

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 > proce

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

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: # 3.2+ > > Cc: Kim Phillips > > Signed-off-by: Ho

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 > >itse

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 ob

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

[PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support

2014-04-28 Thread Naveen Krishna Chatradhi
SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Add

[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 contro

[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 Acked-by: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- Changes since v7: Added Acked-by from Herbert Xu Changes since v6: None Changes since v5: Rewritten the inte

[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 Reviewed-by: Tomasz Figa Ack

[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 is

[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 Reviewed-by: Tomasz Figa Acked-by: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- Changes since v7: Added Acked-by from Herbert Xu Changes since v6: N

[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 Reviewed-by: Tomasz Figa Acked-by: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy

[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 Reviewed-by: Tomasz Figa Acked-by: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- Changes since v7: Added Acked-by from Herbert Xu Changes

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 - A

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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http:/

Re: [PATCH crypto 1/2] crypto: caam - fix mem leak in ahash_setkey

2014-04-28 Thread Herbert Xu
On Wed, Apr 23, 2014 at 01:47:32AM +0200, Marek Vasut wrote: > On Friday, April 18, 2014 at 12:01:41 PM, Horia Geanta wrote: > > In case hash key is bigger than algorithm block size, it is hashed. > > In this case, memory is allocated to keep this hash in hashed_key. > > hashed_key has to be freed

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: # 3.2+ > Cc: Kim Phillips > Signed-off-by: Horia Geanta Patch applied to the crypto tree. Thanks. -- Email: Herbert

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 in-

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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

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 an

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