Re: [PATCH 05/22] hw_random: Fix dependencies for !HAS_IOMEM archs

On 25/01/16 22:24, Richard Weinberger wrote: Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger Reviewed-by: Daniel Thompson Thanks for cleaning up after me! ---

[PATCH 2/3] crypto: Introduce the block request crypto engine framework

Now block cipher engines need to implement and maintain their own queue/thread for processing requests, moreover currently helpers provided for only the queue itself (in crypto_enqueue_request() and crypto_dequeue_request()) but they don't help with the mechanics of driving the hardware (things

[PATCH 3/3] crypto: omap-aes: Support crypto engine framework

Integrate with the newly added crypto engine to make the crypto hardware engine underutilized as each block needs to be processed before the crypto hardware can start working on the next block. The requests from dm-crypt will be listed into engine queue and processed by engine automatically, so

Re: [PATCH 1/2] crypto: jitterentropy - always select CRYPTO_RNG

On Mon, Jan 25, 2016 at 05:50:34PM +0100, Arnd Bergmann wrote: > When building the jitterentropy driver by itself, we get a link error > when CRYPTO_RNG is not enabled as well: > > crypto/built-in.o: In function `jent_mod_init': > jitterentropy-kcapi.c:(.init.text+0x98): undefined reference to >

Re: [PATCH v3 0/4] crypto: add algif_akcipher user space API

On Mon, Jan 25, 2016 at 10:34:53PM +0100, Stephan Mueller wrote: > Am Freitag, 18. Dezember 2015, 00:49:57 schrieb Stephan Mueller: > > Hi Herbert, > > [...] > > > Changes v3: > > * fix hack in alg_setkey and alg_setsockopt by avoding branches for > > setkey and setpubkey as pointed out by

Re: [PATCH 16/26] libceph: Use skcipher

On Tue, Jan 26, 2016 at 12:29:57PM +0100, Ilya Dryomov wrote: > > LGTM. You want to take it through crypto? That's probably the easiest route since I'd like to take the first patch through cryptodev. Thanks, -- Email: Herbert Xu Home Page:

[PATCH 1/3] crypto: Introduce crypto_queue_len() helper function

This patch introduces crypto_queue_len() helper function to help to get the queue length in the crypto queue list now. Signed-off-by: Baolin Wang --- include/crypto/algapi.h |4 1 file changed, 4 insertions(+) diff --git a/include/crypto/algapi.h

Re: [PATCH 1/4] crypto: sunxi - don't print uninitialized data

On Mon, Jan 25, 2016 at 05:53:48PM +0100, Arnd Bergmann wrote: > gcc correctly warns that the printk output contains a variable that > is not initialized in some cases: > > drivers/crypto/sunxi-ss/sun4i-ss-cipher.c: In function 'sun4i_ss_cipher_poll': >

Re: [PATCH 1/2] crypto: jitterentropy - always select CRYPTO_RNG

On Tuesday 26 January 2016 18:30:18 Herbert Xu wrote: > On Mon, Jan 25, 2016 at 05:50:34PM +0100, Arnd Bergmann wrote: > > When building the jitterentropy driver by itself, we get a link error > > when CRYPTO_RNG is not enabled as well: > > > > crypto/built-in.o: In function `jent_mod_init': > >

Re: GCM: cra_name == cra_driver_name

On Mon, Jan 25, 2016 at 10:48:38PM +0100, Stephan Mueller wrote: > Hi Herbert, > > with the current cryptodev tree, when I call a compound AEAD cipher with > cra_driver_name for the first time, this cra_driver_name gets registered also > as cra_name. Note, using other compound ciphers (like

Re: [PATCH 3/4] crypto: kdf - SP800-108 Key Derivation Function

On Tue, Jan 26, 2016 at 07:20:59AM +0100, Stephan Mueller wrote: > > +/* > + * Implementation of the KDF in counter mode according to SP800-108 section > 5.1. > + * > + * The caller must provide Label || 0x00 || Context in src. This src pointer > + * may also be NULL if the caller wishes not to

Re: [PATCH v1] crypto: ccp - Add hash state import and export support

On Mon, Jan 25, 2016 at 08:58:41AM -0600, Tom Lendacky wrote: > > Many of the fields in the rctx structure are set during the update > operation and don't matter to the driver from an export and import > perspective. I included them to make the routines simple, but if > user-space exposure is a

Re: [PATCH 0/4] crypto: Key Derivation Function (SP800-108)

On Tue, Jan 26, 2016 at 07:19:17AM +0100, Stephan Mueller wrote: > Hi, > > this patch set implements all three key derivation functions defined in > SP800-108. > > The implementation is provided as a template for random number generators, > since a KDF can be considered a form of deterministic

Re: [PATCH 0/4] crypto: Key Derivation Function (SP800-108)

Am Mittwoch, 27. Januar 2016, 13:14:09 schrieb Herbert Xu: Hi Herbert, >On Tue, Jan 26, 2016 at 07:19:17AM +0100, Stephan Mueller wrote: >> Hi, >> >> this patch set implements all three key derivation functions defined in >> SP800-108. >> >> The implementation is provided as a template for

Re: [PATCH 0/4] crypto: Key Derivation Function (SP800-108)

On Wed, Jan 27, 2016 at 08:33:00AM +0100, Stephan Mueller wrote: > > With the current development of EXT4 encryption we currently have the > logic that the files are either open (read/writable) or closed (not > accessible). > > There is a scenario for a third option: a file is writable in a

Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression support

On 1/27/2016 3:41 PM, Herbert Xu wrote: On Tue, Jan 26, 2016 at 05:15:06PM +0900, Joonsoo Kim wrote: From: Weigang Li Now, asynchronous compression APIs are supported. There is no asynchronous compression driver now but this APIs can be used as front-end to synchronous

[PATCH v2 07/10] crypto/lz4hc: support new compression APIs

Now, new compression APIs are introduced and it has some benefits. Let's support it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/lz4hc.c | 91 +++--- 2 files changed, 82 insertions(+), 10 deletions(-)

[PATCH v2 04/10] crypto/compress: add asynchronous compression support

From: Weigang Li Now, asynchronous compression APIs are supported. There is no asynchronous compression driver now but this APIs can be used as front-end to synchronous compression algorithm. In this case, scatterlist would be linearlized when needed so it would cause some

[PATCH v2 09/10] crypto/deflate: support new compression APIs

Now, new compression APIs are introduced and it has some benefits. Let's support it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/deflate.c | 110 ++- 2 files changed, 101 insertions(+), 10

[PATCH v2 06/10] crypto/lz4: support new compression APIs

Now, new compression APIs are introduced and it has some benefits. Let's support it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/lz4.c | 91 +++--- 2 files changed, 82 insertions(+), 10 deletions(-)

[PATCH v2 08/10] crypto/842: support new compression APIs

Now, new compression APIs are introduced and it has some benefits. Let's support it. Signed-off-by: Joonsoo Kim --- crypto/842.c | 85 +++--- crypto/Kconfig | 1 + 2 files changed, 83 insertions(+), 3 deletions(-)

[PATCH v2 10/10] crypto/testmgr: add new compression APIs test

New compression APIs are supported now so we need test cases. This patch implements it based on previous compression test framework. Almost changes are straight forward. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/testmgr.c | 227

[PATCH v2 05/10] crypto/lzo: support new compression APIs

Now, new compression APIs are introduced and it has some benefits. Let's support it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/lzo.c | 95 ++ 2 files changed, 83 insertions(+), 13 deletions(-)

[PATCH v2 01/10] crypto/compress: remove unused pcomp interface

It is unused now, so remove it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 19 -- crypto/Makefile| 2 - crypto/pcompress.c | 115 --- crypto/testmgr.c | 223 --

[PATCH v2 03/10] crypto/compress: introduce sychronuous compression API

This introduces new compression APIs. Major change is that APIs are stateless. Instead of previous implementation, tfm objects doesn't embedded any context so we can de/compress concurrently with one tfm object. Instead, this de/compression context is coupled with the request. This architecture

[PATCH v2 02/10] crypto: add algorithm type specific flag, CRYPTO_ALG_PRIVATE

In following patch, new synchronous compression APIs will be introduced and it needs one flags to determine whether context buffer is needed or not for decompression. It can be implemented by flag in it's own algorithm structure definition but because there is a room in general crypto_alg flag,

Re: [PATCH 3/4] crypto: kdf - SP800-108 Key Derivation Function

Am Dienstag, 26. Januar 2016, 18:28:14 schrieb Herbert Xu: Hi Herbert, >On Tue, Jan 26, 2016 at 07:20:59AM +0100, Stephan Mueller wrote: >> +/* >> + * Implementation of the KDF in counter mode according to SP800-108 >> section 5.1. + * >> + * The caller must provide Label || 0x00 || Context in

Re: crypto: algif_hash: creating 0 sized array in hash_accept

On 01/25/2016 08:58 AM, Herbert Xu wrote: > On Mon, Jan 25, 2016 at 07:14:20AM -0500, Sasha Levin wrote: >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running the latest -next >> kernel >> I've hit: >> >> [ 828.386074] UBSAN: Undefined behaviour in

[PATCH v2 1/2] crypto: sunxi - don't print confusing data

gcc correctly warns that the printk output contains a variable that it thinks is not initialized in some cases: drivers/crypto/sunxi-ss/sun4i-ss-cipher.c: In function 'sun4i_ss_cipher_poll': drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:254:76: warning: 'todo' may be used uninitialized in this

[PATCH v2 2/2] crypto: jitterentropy - always select CRYPTO_RNG

When building the jitterentropy driver by itself, we get a link error when CRYPTO_RNG is not enabled as well: crypto/built-in.o: In function `jent_mod_init': jitterentropy-kcapi.c:(.init.text+0x98): undefined reference to `crypto_register_rng' crypto/built-in.o: In function `jent_mod_exit':

Re: crypto: algif_hash: creating 0 sized array in hash_accept

On Tue, Jan 26, 2016 at 08:26:41AM -0500, Sasha Levin wrote: > > This seems to be happening with "digest_null". In that case this is expected as digest_null obviously has no state. So why is a zero-length array disallowed by ubsan? Cheers, -- Email: Herbert Xu

[PATCH] crypto: skcipher - Add helper to retrieve driver name

This patch adds the helper crypto_skcipher_driver_name which returns the driver name of the alg object for a given tfm. This is needed by ecryptfs. Signed-off-by: Herbert Xu diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h index f7a03a1..5bb7056

Re: crypto: algif_hash: creating 0 sized array in hash_accept

On 01/26/2016 09:07 AM, Herbert Xu wrote: > On Tue, Jan 26, 2016 at 08:26:41AM -0500, Sasha Levin wrote: >> > >> > This seems to be happening with "digest_null". > In that case this is expected as digest_null obviously has no > state. So why is a zero-length array disallowed by ubsan? The C spec

Re: crypto: algif_hash: creating 0 sized array in hash_accept

On Tue, Jan 26, 2016 at 09:30:54AM -0500, Sasha Levin wrote: > > The C spec forbids it, so ubsan complains :) If you really care about this then please send a patch that adds ?: 1 to the size. Cheers, -- Email: Herbert Xu Home Page:

Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs

On Tue, Jan 26, 2016 at 12:19:02AM +0300, Anatoly Pugachev wrote: > n2rng: Attach on T5/M5, T7/M7 SPARC CPUs > > (space to tab fixes after variable names) > > Signed-off-by: Anatoly Pugachev Both patches applied. Thanks. -- Email: Herbert Xu

Re: [PATCH 05/22] hw_random: Fix dependencies for !HAS_IOMEM archs

On Mon, Jan 25, 2016 at 11:24:04PM +0100, Richard Weinberger wrote: > Not every arch has io memory. > So, unbreak the build by fixing the dependencies. > > Signed-off-by: Richard Weinberger Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: hash - select CRYPTO_HASH where needed

On Mon, Jan 25, 2016 at 05:51:21PM +0100, Arnd Bergmann wrote: > The ghash and poly1305 hash implementations can be enabled when > CONFIG_CRYPTO_HASH is turned off, causing a link error: > > crypto/built-in.o: In function `ghash_mod_init': > (.init.text+0xd0): undefined reference to

Re: AF_ALG: hash returns -ENOKEY

On Mon, Jan 25, 2016 at 10:22:36PM +0100, Stephan Mueller wrote: > Hi Herbert, > > during testing of the current cryptodev-2.6 key, the AF_ALG hash does not > seem > to work as it used to. Oops, looks like I screwed up shash. ---8<--- Subject: crypto: shash - Fix has_key setting The has_key

Re: AF_ALG: hash returns -ENOKEY

Am Mittwoch, 27. Januar 2016, 00:16:37 schrieb Herbert Xu: Hi Herbert, > On Mon, Jan 25, 2016 at 10:22:36PM +0100, Stephan Mueller wrote: > > Hi Herbert, > > > > during testing of the current cryptodev-2.6 key, the AF_ALG hash does not > > seem to work as it used to. > > Oops, looks like I

Re: [PATCH 17/26] mac802154: Use skcipher

Hello. On 24/01/16 14:18, Herbert Xu wrote: This patch replaces uses of blkcipher with skcipher. Signed-off-by: Herbert Xu --- net/mac802154/llsec.c | 41 +++-- net/mac802154/llsec.h |3 +-- 2 files changed, 24

Re: [PATCH] eCryptfs: Clean up crypto initialization

[fixed mhalcrow's email address] Hi Dan - thanks for the alert. I think the code is fine in this situation. On 2016-01-25 17:23:11, Dan Carpenter wrote: > Hello Michael Halcrow, > > The patch e5d9cbde6ce0: "[PATCH] eCryptfs: Clean up crypto > initialization" from Oct 30, 2006, leads to the

Re: [PATCH] crypto: chacha20_4block_xor_ssse3: Align stack pointer to 64 bytes

Can we queue this up for stable too, please? On Mon, Jan 25, 2016 at 2:59 PM, Herbert Xu wrote: > Patch applied. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH] crypto: chacha20_4block_xor_ssse3: Align stack pointer to 64 bytes

On Wed, Jan 27, 2016 at 01:40:00AM +0100, Jason A. Donenfeld wrote: > Can we queue this up for stable too, please? It'll go to stable automatically once Linus pulls it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH 16/26] libceph: Use skcipher

On Tue, Jan 26, 2016 at 11:54 AM, Herbert Xu wrote: > On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote: >> >> Could you get rid of ivsize instead of assigning to it - see the >> attached diff? > > How about an incremental patch like this? Thanks! > >

Re: GCM: cra_name == cra_driver_name

Am Dienstag, 26. Januar 2016, 19:13:52 schrieb Herbert Xu: Hi Herbert, >On Mon, Jan 25, 2016 at 10:48:38PM +0100, Stephan Mueller wrote: >> Hi Herbert, >> >> with the current cryptodev tree, when I call a compound AEAD cipher with >> cra_driver_name for the first time, this cra_driver_name gets