[PATCH v2 0/2] crypto: AF_ALG memory management fix

Hi Herbert, Changes v2: * import fix from Harsh Jain to remove SG from list before freeing * fix return code used for ki_complete to match AIO behavior with sync behavior * rename variable list -> tsgl_list * update the algif_aead patch to include a dynamic TX SGL

[PATCH v2 2/2] crypto: aead AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

[PATCH v2 1/2] crypto: skcipher AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

Re: [PATCH 1/1] crypto:algif_aead - Fix kernel panic on list_del

Am Mittwoch, 1. Februar 2017, 21:10:28 CET schrieb Harsh Jain: Hi Harsh, > Kernel panics when userspace program try to access AEAD interface. > Remove node from Linked List before freeing its memory. Very good catch. Thank you. Reviewed-by: Stephan Müller <smuel...@chronox.de>

Re: [PATCH v2 4/6] crypto: ecdsa: add ECDSA SW implementation

Am Freitag, 3. Februar 2017, 16:42:53 CET schrieb Nitin Kumbhar: Hi Nitin, > + > +int ecdsa_set_pub_key(struct crypto_akcipher *tfm, const void *key, > + unsigned int keylen) > +{ > + struct ecdsa_ctx *ctx = ecdsa_get_ctx(tfm); > + struct ecdsa params; > + unsigned

Re: [PATCH 0/6] Add support for ECDSA algorithm

Am Donnerstag, 2. Februar 2017, 21:57:21 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 26, 2017 at 11:30:04AM +0530, Nitin Kumbhar wrote: > > This ECDSA implementation is analogous to the RSA kernel implementation > > for > > signature generation / verification. It extends ECC family of

Re: [PATCH] crypto: doc - Fix hash export state information

Am Mittwoch, 25. Januar 2017, 16:55:06 CET schrieb Rabin Vincent: Hi Rabin, > From: Rabin Vincent > > The documentation states that crypto_ahash_reqsize() provides the size > of the state structure used by crypto_ahash_export(). But it's actually > crypto_ahash_statesize()

Re: [PATCH 0/6] Add support for ECDSA algorithm

Am Donnerstag, 26. Januar 2017, 11:30:04 CET schrieb Nitin Kumbhar: Hi Nitin, > > Who is going to use this in the kernel? > > This ECDSA implementation is analogous to the RSA kernel implementation > for signature generation / verification. It extends ECC family of > algorithms like ECDH to

Re: [PATCH 5/6] crypto: testmgr: add ECDSA tests

Am Freitag, 20. Januar 2017, 17:06:00 CET schrieb Nitin Kumbhar: Hi Nitin, > Update crypto test manager to include NIST ECDSA > test vectors and various ECDSA tests. These include > tests for ECDSA signing, ECDSA sign-verification, > ECDSA signing and verifying generated signatures and >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 20. Januar 2017, 18:07:04 CET schrieb Cyrille Pitchen: Hi Cyrille, > > I've taken Stephan's other comments into account from his review of the > atmel-authenc driver so I'm preparing a new series but I don't know what to > do for the associated data copy. > > Please let me know

[PATCH v5 0/2] crypto: AF_ALG memory management fix

Hi Herbert, Changes v5: * use list_for_each_entry_safe in aead_count_tsgl Changes v4: * replace ctx->processed with a maintenance of a private recvmsg TX SGL * algif_skcipher: rename skcipher_sg_list into skcipher_tsgl to make it consistent with algif_aead to prepare for a code consolidation

[PATCH v5 2/2] crypto: aead AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

Re: BUG: af_alg bind fails for 50 % request from userspace for hash algo

Am Mittwoch, 15. Februar 2017, 22:12:16 CET schrieb Harsh Jain: Hi Harsh, > Hi Herbert/Stephen, > > When I try to run 100 application which calculates sha384 digest from > userspace, nearly 50 applications fail in bind system call with error > ENOENT. > > "crypto_alg_mod_lookup" in api.c call

[PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

Re: [PATCH v4 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Donnerstag, 16. Februar 2017, 22:21:44 CET schrieb Stephan Müller: Hi, > +static unsigned int skcipher_count_tsgl(struct sock *sk, size_t bytes) > { > struct alg_sock *ask = alg_sk(sk); > struct skcipher_ctx *ctx = ask->private; > - struct skc

[RFC] how to handle AAD copy operation for algif_aead

Hi Herbert et al, attached are two patches where each patch has a different approach to copy the AAD in the algif_aead operation. I would like to hear your opinion which approach should be taken. The patch 0001-crypto-algif_aead-copy-AAD-from-src-to-dst_separate.patch simply copies the AAD

Re: [PATCH] Revert "hwrng: core - zeroize buffers with random data"

Am Mittwoch, 8. Februar 2017, 17:57:23 CET schrieb Linus Torvalds: Hi Linus, > Stephan, Herbert? The zeroes in /dev/hwrng output are obviously > complete crap, so there's something badly wrong somewhere. > > The locking, for example, is completely buggered. There's even a > comment about it,

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

Am Donnerstag, 9. Februar 2017, 02:04:32 CET schrieb Alden Tondettar: Hi Alden, > On Thu, Feb 09, 2017 at 07:47:25AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote: > > > In short, the situation is: > > > > > > A) No usable hardware RNG or

Re: Qualcomm QCE driver: XTS setkey only allows 128 bit AES

Am Mittwoch, 15. Februar 2017, 12:02:43 CET schrieb Herbert Xu: Hi Herbert, > Stephan Müller <smuel...@chronox.de> wrote: > > Hi, > > > > The Qualcomm QCE driver implementation defines: > >.flags = QCE_ALG_AES | QCE_MODE_XTS, > >

Qualcomm QCE driver: XTS setkey only allows 128 bit AES

Hi, The Qualcomm QCE driver implementation defines: .flags = QCE_ALG_AES | QCE_MODE_XTS, .name = "xts(aes)", .drv_name = "xts-aes-qce", .blocksize = AES_BLOCK_SIZE, .ivsize =

[PATCH v3 0/2] crypto: AF_ALG memory management fix

Hi Herbert, Changes v3: * in *_pull_tsgl: make sure ctx->processed cannot be less than zero * perform fuzzing of all input parameters with bogus values Changes v2: * import fix from Harsh Jain to remove SG from list before freeing * fix return code used for ki_complete to

[PATCH v3 2/2] crypto: aead AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

[PATCH v3 1/2] crypto: skcipher AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

Re: [PATCH v5] KEYS: add SP800-56A KDF support for DH

Am Freitag, 19. August 2016, 20:39:09 CET schrieb Stephan Mueller: Hi David, > Hi, > > This patch now folds the KDF into the keys support as requested by > Herbert. The caller can only supply the hash name used for the KDF. > > Note, the KDF implementation is identical to the kdf_ctr() support

Re: [PATCH v3 0/2] crypto: AF_ALG memory management fix

Am Donnerstag, 16. Februar 2017, 20:10:21 CET schrieb Herbert Xu: Hi Herbert, > On Wed, Feb 15, 2017 at 09:47:19AM +0100, Stephan Müller wrote: > > as I just saw that you marked my patch with changes requested in > > patchwork, > > may I ask which changes should be appli

[PATCH v4 2/2] crypto: aead AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

[PATCH v4 0/2] crypto: AF_ALG memory management fix

Hi Herbert, Changes v4: * replace ctx->processed with a maintenance of a private recvmsg TX SGL * algif_skcipher: rename skcipher_sg_list into skcipher_tsgl to make it consistent with algif_aead to prepare for a code consolidation Changes v3: * in *_pull_tsgl: make sure ctx->processed cannot

[PATCH v4 1/2] crypto: skcipher AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote: > > > If you're making a single call, what guarantees the ordering? > > > > Technically, io_submit is the syscall that trigg

Re: [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

Am Dienstag, 17. Januar 2017, 23:12:50 CET schrieb Theodore Ts'o: Hi Theodore, > On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote: > > The random_ready callback mechanism is intended to replicate the > > getrandom system call behavior to in-kernel users. As the getra

Re: [PATCH 4/6] crypto: ecdsa: add ECDSA SW implementation

Am Freitag, 20. Januar 2017, 17:05:59 CET schrieb Nitin Kumbhar: Hi Nitin, > This adds support for ECDSA algorithm. This implementation supports > sign and verify functions for ECDSA algorithm using akcipher. As ECDSA > is a signing algorithm dummy functions are added for encrypt() and >

Re: Problem with RSA test from testmgr

Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe: Hi Corentin, > hello > > I work on the sun8i-ce crypto accelerator and I have some problem with the > RSA part. > > The RSA register fail at the first RSA test (encrypt 512bit) with this > output: [ 8480.146843] alg: akcipher:

Re: Problem with RSA test from testmgr

Am Dienstag, 28. Februar 2017, 17:45:53 CET schrieb Corentin Labbe: Hi Corentin, > On Tue, Feb 28, 2017 at 05:08:35PM +0100, Stephan Müller wrote: > > Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe: > > > > Hi Corentin, > > > > > hello

Re: Problem with RSA test from testmgr

Am Mittwoch, 1. März 2017, 13:04:14 CET schrieb Corentin Labbe: Hi Corentin, > > I got the following: > > [1.086228] alg: akcipher: encrypt test failed. Invalid output > [1.092196] : 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db > [1.098882] 0010: c9 b2 db 43 bd 9a b9

Re: Problem with RSA test from testmgr

Am Donnerstag, 2. März 2017, 03:15:13 CET schrieb Tadeusz Struk: Hi Tadeusz, > > memset(ptextp, 0, 256); > memcpy(ptextp + 64 - 8, ptext_ex, plen); I actually have tested that and it did not return the data the kernel implementation would return Ciao Stephan

Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx

Am Dienstag, 13. Dezember 2016, 14:50:59 CET schrieb Jonathan Corbet: Hi Jonathan, > On Tue, 13 Dec 2016 22:25:07 +0100 > > Stephan Müller <smuel...@chronox.de> wrote: > > Considering that a large batch of documentation updates just landed in > > Linus' tree, I am w

Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx

Am Dienstag, 13. Dezember 2016, 16:40:01 CET schrieb Jonathan Corbet: Hi Jonathan, > Clearly there was a bit of misunderstanding going around :) Yep, it seems like it :-) > > I've applied the patch set to docs-next. Oddly I had no trouble with #7, > but #2 was badly mailer-mangled and took

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

Am Freitag, 16. Dezember 2016, 19:54:36 CET schrieb Herbert Xu: Hi Herbert, > On Tue, Dec 13, 2016 at 09:42:45PM +0100, Stephan Müller wrote: > > + /* > > +* The async operation may have processed only a subset of > > +* the data that was in

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

Am Freitag, 16. Dezember 2016, 20:31:27 CET schrieb Herbert Xu: Hi Herbert, > > > > You are right, this will introduce a memleak. But with the immediate > > freeing of sreq->tsg in the current code, the AIO interface cannot > > support multiple IOCBs. > > > > Thus, the entire memory handling in

[PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

Hi Herbert, I am sorry to interrupt your merge window, but may I ask to consider this patch for the current development cycle as well as for stable back to v4.1 where the algif_skcipher AIO support was added? It fixes the two bug reports which I reported back in September that allow crashing the

Re: [PATCH v4] crypto: AF_ALG - fix AEAD tag memory handling

Am Mittwoch, 7. Dezember 2016, 19:42:45 CET schrieb Herbert Xu: Hi Herbert, > > Hmm, I don't see the code that copies the AAD over. Did I miss it? You do not miss it. As I mentioned in a previous email, I would like: - to include the current patch around the tag now as it has been on the

Re: [PATCH v4] crypto: AF_ALG - fix AEAD tag memory handling

Am Mittwoch, 7. Dezember 2016, 20:09:14 CET schrieb Herbert Xu: Hi Herbert, > On Mon, Dec 05, 2016 at 03:26:19PM +0100, Stephan Mueller wrote: > > Hi Herbert, > > > > Changes v4: restore the old behavior -- if the caller does not provide > > sufficient output buffer size, return an error. > >

Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx

Am Dienstag, 25. Oktober 2016, 10:35:49 CET schrieb Herbert Xu: Hi Jonathan, > > > > the attached patch set converts the existing crypto API documentation > > > > from DocBook to Sphinx. > > > > > > This looks generally good to me - thanks for doing it! > > > > > > Is there any chance of

[ANNOUNCE] libkcapi v0.13.0 released

Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does

[PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Hi, to all driver maintainers: the patches I added are compile tested, but I do not have the hardware to verify the code. May I ask the respective hardware maintainers to verify that the code is appropriate and works as intended? Thanks a lot. Herbert, this is my proprosal for our discussion

[PATCH 01/13] crypto: service function to copy AAD from src to dst

The service function crypto_aead_copy_ad uses the null cipher to copy the AAD from teh source to the destination SGL. The copy operation is prevented when the source and destination SGL is identical. The required null cipher is allocated during the allocation of the TFM and released with the TFM.

[PATCH 06/13] crypto: talitos - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/talitos.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/talitos.c

[PATCH 13/13] crypto: qat - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/qat/qat_common/qat_algs.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 03/13] crypto: ccm_generic - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- crypto/ccm.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/crypto/ccm.c b/crypto/ccm.c

[PATCH 02/13] crypto: gcm_generic - copy AAD during encryption

>From 8690e52f7e90663b14b2490d37a3b5b1c5a53bfe Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Mon, 9 Jan 2017 12:35:35 +0100 Subject: Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer.

[PATCH 05/13] crypto: ccm-aes-ce - copy AAD during encryption

>From acad5f6af68d18bc1dbac460bd44f2298902018b Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Mon, 9 Jan 2017 14:32:02 +0100 Subject: Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer.

[PATCH 12/13] crypto: nx - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/nx/nx-aes-ccm.c | 4 drivers/crypto/nx/nx-aes-gcm.c | 10 ++ 2 files changed,

[PATCH 11/13] crypto: chelsio - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/chelsio/chcr_algo.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 08/13] crypto: ixp4xx - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/ixp4xx_crypto.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 10/13] crypto: caam - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/caam/caamalg.c | 8 1 file changed, 8 insertions(+) diff --git

[PATCH 09/13] crypto: atmel - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/atmel-aes.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 07/13] crypto: picoxcell - copy AAD during encryption

Invoke the crypto_aead_copy_ad function during the encryption code path to copy the AAD from the source to the destination buffer. Signed-off-by: Stephan Mueller --- drivers/crypto/picoxcell_crypto.c | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu: Hi Herbert, > On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote: > > to all driver maintainers: the patches I added are compile tested, but > > I do not have the hardware to verify the code. May I ask

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu: Hi Herbert, > > I think it's too much churn. Let's get the algif_aead code fixed > up first, and then pursue this later. To eliminate the extra churn of having all AEAD implementations changed to invoke copy operation, what

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 22:57:28 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote: > > When addressing the issue in the algif_aead code, and expect that over > > time > > the AEAD implementations will gain the copy

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:27:10 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote: > > As far as I understand, we have the following AAD copy operations that we > > discuss: > > > > - algif_aead: you su

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 00:17:59 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote: > > Each IOCB would transpire into an independent, separate recvmsg invocation > > without an additional sendmsg/sendpage operation.

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:53:44 CET schrieb Herbert Xu: Hi Herbert, > > > If we only want to solve that for algif_aead, wouldn't it make more sense > > if the user space caller takes care of that (such as libkcapi)? By > > tinkering with the SGLs and copying the data to the dst buffer

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller: Hi Herbert, > > That would mean that we would only support one IOCB. As we also need to be standards compliant, would it be appropriate to only support one IOCB? I think this is a significant difference to oth

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 00:06:29 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote: > > I fully agree. Therefore, I was under the impression that disregarding the > > AAD in recvmsg entirely would be most appropr

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:39:24 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 04:34:39PM +0100, Stephan Müller wrote: > > We would only be able to remove it if all AEAD implementations are > > converted. But for the conversion time, we do face that issue.

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Donnerstag, 12. Januar 2017, 23:51:28 CET schrieb Herbert Xu: Hi Herbert, > On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote: > > + * The following concept of the memory management is used: > > + * > > + * The kernel maintains two SGLs, the TX SGL and t

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 00:07:39 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:05:03PM +0100, Stephan Müller wrote: > > Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller: > > > > Hi Herbert, > > > > > That would mean

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:12:59 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote: > > > Well if ordering is not guaranteed that I don't see how your code > > > can work either. Or am I missing something? > >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:26:23 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote: > > That is correct, but I thought that playing with pointers is always faster > > than doing memcpy. Are you saying that this assumption i

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:03:35 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote: > > According to the man page of lio_listio(3) the provided AIO operations are > > executed in an unspecified order. I would infer from

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:33:24 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote: > > So, the patch set you want to see is: > > > > - remove the AAD copy operation from authenc and not add it to any AEAD > &g

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 18:23:39 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote: > > I would not understand that statement. > > > > With the patch mentioned above that I provided some weeks ago, we have the &

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:04:17 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote: > > May I ask how the in-place code path can be invoked by algif_aead or > > algif_skcipher? As far as I understand, this code path is only i

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:14:06 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote: > > Adding such code should IMHO not be impaired by pointing to the AAD held > > in > > the src SGL by the dst SGL as offered with the

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote: > > > If you're making a single call, what guarantees the ordering? > > > > Technically, io_submit is the syscall that trigg

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 18:21:45 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote: > > > I don't understand, what's wrong with: > > > > > > sendmsg(fd, ...) > > > aio_read(iocb1) > > > send

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Am Mittwoch, 11. Januar 2017, 16:58:17 CET schrieb George Cherian: Hi George, > I will add a seperate function for xts setkey and make changes as following. > > ... > > > >> + > >> +struct crypto_alg algs[] = { { > >> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC, > >> +

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Am Mittwoch, 11. Januar 2017, 10:56:50 CET schrieb George Cherian: Hi George, > +int cvm_enc_dec_setkey(struct crypto_ablkcipher *cipher, const u8 *key, > +u32 keylen) > +{ > + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher); > + struct cvm_enc_ctx *ctx =

Re: Is the asynchronous hash crypto API asynchronous?

t it is helpful. > > On Mon, Jan 9, 2017 at 12:23 PM, Stephan Müller <smuel...@chronox.de> wrote: > > Am Sonntag, 8. Januar 2017, 15:45:37 CET schrieb Gilad Ben-Yossef: > > > > Hi Gilad, > > > >> ahash_request_set_callback(req, 0, NULL, N

Re: Is the asynchronous hash crypto API asynchronous?

Am Sonntag, 8. Januar 2017, 15:45:37 CET schrieb Gilad Ben-Yossef: Hi Gilad, > ahash_request_set_callback(req, 0, NULL, NULL); > > Would anyone be kind enough to enlighten me? The documentation got out of sync with the real world. I will file a patch for that shortly. The ahash API

Re: [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Am Montag, 9. Januar 2017, 19:24:12 CET schrieb Cyrille Pitchen: Hi Cyrille, > >> +static int atmel_aes_authenc_copy_assoc(struct aead_request *req) > >> +{ > >> + size_t buflen, assoclen = req->assoclen; > >> + off_t skip = 0; > >> + u8 buf[256]; > >> + > >> + while (assoclen) { > >> +

Re: simd ciphers

Am Donnerstag, 29. Dezember 2016, 17:44:15 CET schrieb Herbert Xu: Hi Herbert, > On Wed, Dec 28, 2016 at 12:21:52PM +0100, Stephan Müller wrote: > > This patch does not help. But I now found the issue: we need some Kconfig > > wizardry to mandate pcbc to be compiled statica

Re: [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Am Donnerstag, 22. Dezember 2016, 17:38:00 CET schrieb Cyrille Pitchen: Hi Cyrille, > This patchs allows to combine the AES and SHA hardware accelerators on > some Atmel SoCs. Doing so, AES blocks are only written to/read from the > AES hardware. Those blocks are also transferred from the AES to

Re: simd ciphers

Am Mittwoch, 28. Dezember 2016, 18:28:26 CET schrieb Herbert Xu: Hi Herbert, > On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote: > > When I configure AES-NI as module, it works. When compiling it statically, > > the allocation returns an -ENOENT. > > >

[ANNOUNCE] /dev/random - a new approach (code for 4.10-rc1)

Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time

[PATCH 6/8] random: fix comment for unused random_min_urandom_seed

The variable random_min_urandom_seed is not needed any more as it defined the reseeding behavior of the nonblocking pool. Though it is not needed any more, it is left in the code for user space interface compatibility. Signed-off-by: Stephan Mueller ---

[PATCH 0/8] random: cleanup of code after removal of nonblocking pool

Hi Ted, with the removal of the nonblocking_pool, several code paths are now unused which were only applicable to the nonblocking pool. This patch set removes these unused code paths. Also, a code path in the add_interrupt_randomness function that is never used is removed. In addition, the FIPS

[PATCH 5/8] random: remove variable limit

The variable limit was used to identify the nonblocking pool's unlimited random number generation. As the nonblocking pool is a thing of the past, remove the limit variable and any conditions around it (i.e. preserve the branches for limit == 1). Signed-off-by: Stephan Mueller

[PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

The random_ready callback mechanism is intended to replicate the getrandom system call behavior to in-kernel users. As the getrandom system call unblocks with crng_init == 1, trigger the random_ready wakeup call at the same time. Signed-off-by: Stephan Mueller ---

[PATCH 2/8] random: remove stale urandom_init_wait

The urandom_init_wait wait queue is a left over from the pre-ChaCha20 times and can therefore be savely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index

[PATCH 8/8] random: move FIPS continuous test to output functions

The current lockation of the FIPS continuous self test covers the input_pool only. However, the FIPS continuous self test shall cover the output of the random number generator, i.e. the blocking pool and the ChaCha20 DRNG. This patch therefore moves the continuous test to the output function used

[PATCH 7/8] random: remove noop function call to xfer_secondary_pool

Since the introduction of the ChaCha20 DRNG, extract_entropy is only invoked with the input_pool. For this entropy pool, xfer_secondary_pool is a no-op and can therefore be safely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1

[PATCH 1/8] random: remove stale maybe_reseed_primary_crng

>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Thu, 15 Dec 2016 12:42:33 +0100 Subject: The function maybe_reseed_primary_crng is not used anywhere and thus can be removed. Besides, it contains the check crng_init >

[PATCH 4/8] random: remove unused branch in hot code path

The variable ip is defined to be a __u64 which is always 8 bytes on any architecture. Thus, the check for sizeof(ip) > 4 will always be true. As the check happens in a hot code path, remove the branch. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 3 +-- 1

Re: simd ciphers

Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller: Hi Herbert, > Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller: > > Hi Herbert, > > > Hi Herbert, > > > > with the addition of the simd cipher change I seem to be unable to

Re: simd ciphers

Am Mittwoch, 28. Dezember 2016, 16:59:38 CET schrieb Herbert Xu: Hi Herbert, > > With 4.10-rc1, I also do not get the AES-NI implementations to work. do > > you > > have any ideas what may be the issue? > > I'm having problems reproducing this. Does it work for you if you > build them as

[PATCH 0/2] crypto: AF_ALG memory management fix

Hi Herbert, please find attached memory management updates to - simplify the code: the old AIO memory management is very complex and seemingly very fragile -- the update now eliminates all reported bugs in the skcipher and AEAD interfaces which allowed the kernel to be crashed by an

[PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

[PATCH 2/2] crypto: skcipher AF_ALG - overhaul memory management

The updated memory management is described in the top part of the code. As one benefit of the changed memory management, the AIO and synchronous operation is now implemented in one common function. The AF_ALG operation uses the async kernel crypto API interface for each cipher operation. Thus, the

  1   2   3   4   >