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: [RFC PATCH v2] crypto: Add IV generation algorithms

Hi Milan, Thank you for the reply. On 13 December 2016 at 15:31, Milan Broz wrote: > I really do not think the disk encryption key management should be moved > outside of dm-crypt. We cannot then change key structure later easily. Yes, I agree. but the key selection based

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Wed, Dec 14, 2016 at 01:05:51PM +0800, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote: > > > > I have found two solutions: > > No we already have algif_rng so let's not confuse things even > further by making hwrng take PRNGs. > But algif_rng is not

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote: > > I have found two solutions: No we already have algif_rng so let's not confuse things even further by making hwrng take PRNGs. Cheers, -- Email: Herbert Xu Home Page:

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Tue, Dec 13, 2016 at 09:06:31AM -0800, Andy Lutomirski wrote: > > > Having 0 as type and CRYPTO_ALG_ASYNC as mask in general means > > that we're requesting a sync algorithm (i.e., ASYNC bit off). > > > > However, it is completely unnecessary for shash as they can never > > be async. So this

[PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A.

[PATCH v2 2/4] siphash: add convenience functions for jhash converts

Many jhash users currently rely on the Nwords functions. In order to make transitions to siphash fit something people already know about, we provide analog functions here. This also winds up being nice for the networking stack, where hashing 32-bit fields is common. Signed-off-by: Jason A.

[PATCH v2 4/4] random: use siphash24 instead of md5 for get_random_int/long

This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase

[PATCH v2 1/4] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > The driver put a constant buffer of all zeros on the stack and > pointed a scatterlist entry at it in two places. This doesn't work > with virtual stacks. Use ZERO_PAGE instead. Wait a second... > -

[PATCH v2] wusbcore: Fix one more crypto-on-the-stack bug

The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers Signed-off-by: Andy Lutomirski

[PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it in two places. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers Signed-off-by: Andy Lutomirski

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

On Tue, 13 Dec 2016 23:06:14 +0100 Stephan Müller wrote: > I am sorry, then I may have misunderstood you. > > I would think that Herbert agreed that you push the entire patch set through > your tree, including the documentation changes to the crypto header files. > > I

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

Hi Linus, On Tue, Dec 13, 2016 at 8:25 PM, Linus Torvalds wrote: > Yeah,. the TCP sequence number md5_transform() cases are likely the > best example of something where siphash might be good. That tends to > be really just a couple words of data (the address and

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

Hi Eric, On Tue, Dec 13, 2016 at 9:39 AM, Eric Biggers wrote: > Hmm, I don't think you can really do load_unaligned_zeropad() without first > checking for 'left != 0'. The fixup section for load_unaligned_zeropad() > assumes that rounding the pointer down to a word boundary

[PATCH v4] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

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 wrote: > > Considering that a large batch of documentation updates just landed in > > Linus' tree, I am wondering why the crypto API

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

On Tue, 13 Dec 2016 22:25:07 +0100 Stephan Müller wrote: > Considering that a large batch of documentation updates just landed in Linus' > tree, I am wondering why the crypto API documentation update is not among it. Well, I'd asked if I could run the

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

[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] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > I don't know whether you're right, but that sounds a bit silly to me. > This is a *tiny* amount of memory. Assuming a 1MiB kernel image in 4K pages, that gets you back a couple of pages I think - useful if you've only got a few MiB of RAM. David --

Re: [PATCH v2 2/2] crypto: mediatek - add DT bindings documentation

On Tue, Dec 13, 2016 at 09:31:16AM +0800, Ryder Lee wrote: > Add DT bindings documentation for the crypto driver > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 > ++ > 1 file changed, 32 insertions(+) >

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Tue, Dec 13, 2016 at 12:39 AM, Eric Biggers wrote: > > Hmm, I don't think you can really do load_unaligned_zeropad() without first > checking for 'left != 0'. Right you are. If the allocation is at the end of a page, the 0-size case would be entirely outside the page and

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 3:04 PM, Jason A. Donenfeld wrote: > > Indeed this would be a great first candidate. There are lots of places > where MD5 (!!) is pulled in for this sort of thing, when SipHash could > be a faster and leaner replacement (and arguably more secure than >

Re: [PATCH] crypto: aesni-intel - RFC4106 can zero copy when !PageHighMem

On 12/13/16 04:32 PM, Ilya Lesokhin wrote: > --- a/arch/x86/crypto/aesni-intel_glue.c > +++ b/arch/x86/crypto/aesni-intel_glue.c > @@ -903,9 +903,11 @@ static int helper_rfc4106_encrypt(struct aead_request > *req) > *((__be32 *)(iv+12)) = counter; > > if (sg_is_last(req->src) && > -

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu wrote: > On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote: >> >> Here's my status. >> >> > drivers/crypto/bfin_crc.c:351 >> > drivers/crypto/qce/sha.c:299 >> >

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

Andy Lutomirski writes: > On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote: >> Andy Lutomirski writes: >> >>> Eric Biggers pointed out that the orinoco driver pointed scatterlists >>> at the stack. >>> >>> Fix it by switching from

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > After all, rodata is ordinary memory, is backed by struct page, etc. Is that actually true? I thought some arches excluded the kernel image from the page struct array to make the array consume less memory. David -- To unsubscribe from this list:

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote: > Andy Lutomirski writes: > >> Eric Biggers pointed out that the orinoco driver pointed scatterlists >> at the stack. >> >> Fix it by switching from ahash to shash. The result should be >> simpler, faster,

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

[add some people who might know] On Tue, Dec 13, 2016 at 4:20 AM, David Laight wrote: > From: Andy Lutomirski >> Sent: 12 December 2016 20:53 >> The driver put a constant buffer of all zeros on the stack and >> pointed a scatterlist entry at it in two places. This

[PATCH v2 0/3] Add Support for Cavium Cryptographic Accelerarion Unit

This series adds the support for Cavium Cryptographic Accelerarion Unit (CPT) CPT is available in Cavium's Octeon-Tx SoC series. The series was tested with ecryptfs and dm-crypt for in

Re: [PATCH v6 2/2] crypto: add virtio-crypto driver

On 12/12/2016 11:05 PM, Michael S. Tsirkin wrote: > On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote: >> On Mon, Dec 12, 2016 at 06:25:12AM +, Gonglei (Arei) wrote: >>> Hi, Michael & Herbert >>> >>> Because the virtio-crypto device emulation had been in QEMU 2.8, >>> would you

[PATCH v2 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

Enable the Physical Function diver for the Cavium Crypto Engine (CPT) found in Octeon-tx series of SoC's. CPT is the Cryptographic Acceleration Unit. CPT includes microcoded GigaCypher symmetric engines (SEs) and asymmetric engines (AEs). Signed-off-by: George Cherian

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Tue, Dec 13, 2016 at 08:53:54PM +0530, PrasannaKumar Muralidharan wrote: > > What do you think about those two solutions ? > > I prefer the second solution's idea of using two files (/dev/hwrng and > /dev/hwprng). Upon having a quick glance it looks like (based on > current_rng == prng check)

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

> What do you think about those two solutions ? I prefer the second solution's idea of using two files (/dev/hwrng and /dev/hwprng). Upon having a quick glance it looks like (based on current_rng == prng check) that your current implementation allows only one rng device to be in use at a time. It

[PATCH v2 2/7] hwrng: core: rewrite better comparison to NULL

This patch fix the checkpatch warning "Comparison to NULL could be written "!ptr" Signed-off-by: Corentin Labbe --- drivers/char/hw_random/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/hw_random/core.c

[PATCH v2 3/7] hwrng: core: Rewrite the header

checkpatch have lot of complaint about header. Furthermore, the header have some offtopic/useless information. This patch rewrite a proper header. Signed-off-by: Corentin Labbe --- drivers/char/hw_random/core.c | 38 +- 1 file

[PATCH v2 4/7] hwrng: core: Replace asm/uaccess.h by linux/uaccess.h

This patch fix the checkpatch warning about asm/uaccess.h. In the same time, we sort the headers in alphabetical order. Signed-off-by: Corentin Labbe --- drivers/char/hw_random/core.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH v2 7/7] hwrng: core: Remove linux/sched.h from includes

linux/sched.h is useless for hw_random/core.c. This patch remove it. Signed-off-by: Corentin Labbe --- Change since v1: - linux/fs.h was needed, keep it drivers/char/hw_random/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/hw_random/core.c

[PATCH v2 6/7] hwrng: core: remove unused PFX macro

This patch remove the unused PFX macro. Signed-off-by: Corentin Labbe --- drivers/char/hw_random/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index 1e1e385..5c654b5 100644 ---

[PATCH v2 5/7] hwrng: core: Move hwrng miscdev minor number to include/linux/miscdevice.h

This patch move the define for hwrng's miscdev minor number to include/linux/miscdevice.h. It's better that all minor number are in the same place. Rename it to HWRNG_MINOR (from RNG_MISCDEV_MINOR) in he process since no other miscdev define have MISCDEV in their name. Signed-off-by: Corentin

[PATCH v2 1/7] hwrng: core: do not use multiple blank lines

This patch fix the checkpatch warning "Please don't use multiple blank lines" Signed-off-by: Corentin Labbe --- drivers/char/hw_random/core.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index

[PATCH] crypto: aesni-intel - RFC4106 can zero copy when !PageHighMem

In the common case of !PageHighMem we can do zero copy crypto even if sg crosses a pages boundary. Signed-off-by: Ilya Lesokhin --- arch/x86/crypto/aesni-intel_glue.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[PATCH] crypto: bring back alphabetical order of Makefile

THe major content of drivers/crypto/Makefile is sorted, only recent addition break this sort. This patch bring back this alphabetical sorting. Signed-off-by: Corentin Labbe --- drivers/crypto/Makefile | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)

[PATCH v2 3/3] drivers: crypto: Enable CPT options crypto for build

Add the CPT options in crypto Kconfig and update the crypto Makefile Signed-off-by: George Cherian --- drivers/crypto/Kconfig | 1 + drivers/crypto/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index

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

Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit in Octeon-tx series of processors. Signed-off-by: George Cherian --- drivers/crypto/cavium/cpt/Makefile | 3 +- drivers/crypto/cavium/cpt/cptvf.h| 145

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote: > On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote: > > > > So I must expose it as a crypto_rng ? > > If it is to be exposed at all then algif_rng would be the best > place. > > > Could you explain why PRNG must not be

Re: [RFC PATCH 1/3] crypto: zip - Add ThunderX ZIP driver core

Hello I have some comment below On Mon, Dec 12, 2016 at 04:04:37PM +0100, Jan Glauber wrote: > From: Mahipal Challa > [...] > --- a/drivers/crypto/Makefile > +++ b/drivers/crypto/Makefile > @@ -27,6 +27,7 @@ obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o >

[PATCH] crypto: skcipher - fix crash in virtual walk

The new skcipher walk API may crash in the following way. (Interestingly, the tcrypt boot time tests seem unaffected, while an explicit test using the module triggers it) Unable to handle kernel NULL pointer dereference at virtual address ... [] __memcpy+0x84/0x180 []

Crypto Update for 4.10

Hi Linus: Here is the crypto update for 4.10: API: - Add skcipher walk interface. - Add asynchronous compression (acomp) interface. - Fix algif_aed AIO handling of zero buffer. Algorithms: - Fix unaligned access in poly1305. - Fix DRBG output to large buffers. Drivers: - Add support for

Re: [PATCH] cifs: Fix smbencrypt() to stop pointing a scatterlist at the stack

On Mon, 2016-12-12 at 12:54 -0800, Andy Lutomirski wrote: > smbencrypt() points a scatterlist to the stack, which is breaks if > CONFIG_VMAP_STACK=y. > > Fix it by switching to crypto_cipher_encrypt_one(). The new code > should be considerably faster as an added benefit. > > This code is nearly

RE: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

From: Andy Lutomirski > Sent: 12 December 2016 20:53 > The driver put a constant buffer of all zeros on the stack and > pointed a scatterlist entry at it in two places. This doesn't work > with virtual stacks. Use a static 16-byte buffer of zeros instead. ... I didn't think you could dma from

Re: [PATCH] cifs: Fix smbencrypt() to stop pointing a scatterlist at the stack

Hello! On 12/12/2016 11:54 PM, Andy Lutomirski wrote: smbencrypt() points a scatterlist to the stack, which is breaks if s/is//. CONFIG_VMAP_STACK=y. Fix it by switching to crypto_cipher_encrypt_one(). The new code should be considerably faster as an added benefit. This code is

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

Andy Lutomirski writes: > Eric Biggers pointed out that the orinoco driver pointed scatterlists > at the stack. > > Fix it by switching from ahash to shash. The result should be > simpler, faster, and more correct. > > Cc: sta...@vger.kernel.org # 4.9 only > Reported-by: Eric

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On 12/13/2016 09:49 AM, Binoy Jayan wrote: > Currently, the iv generation algorithms are implemented in dm-crypt.c. > The goal is to move these algorithms from the dm layer to the kernel > crypto layer by implementing them as template ciphers so they can be > implemented in hardware for

[PATCH 2/2] sign-file: Fix inplace signing when src and dst names are both specified

From: Alex Yashchenko When src and dst both are specified and they point to the same file the sign-file utility will write only signature to the dst file and the module (.ko file) body will not be written. That happens because we open the same file with "rb" and "wb"

[PATCH 1/2] crypto: asymmetric_keys: set error code on failure

From: Pan Bian In function public_key_verify_signature(), returns variable ret on error paths. When the call to kmalloc() fails, the value of ret is 0, and it is not set to an errno before returning. This patch fixes the bug. Bugzilla:

[RFC PATCH v2] crypto: Add IV generation algorithms

Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal is to move these algorithms from the dm layer to the kernel crypto layer by implementing them as template ciphers so they can be implemented in hardware for performance. As part of this patchset, the iv-generation code

[RFC PATCH v2] IV Generation algorithms for dm-crypt

=== GENIV Template cipher === Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal is to move these algorithms from

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 11:18:32PM +0100, Jason A. Donenfeld wrote: > + for (; data != end; data += sizeof(u64)) { > + m = get_unaligned_le64(data); > + v3 ^= m; > + SIPROUND; > + SIPROUND; > + v0 ^= m; > + } > +#if