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

On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote: > +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key, > u8 *da, u8 *sa, u8 priority, > u8 *data, size_t data_len, u8 *mic) > { > - AHASH_REQUEST_ON_STACK(req, tfm_michael); > - struct

Re: [PATCH] crypto: Make a few drivers depend on !VMAP_STACK

On Mon, Dec 12, 2016 at 12:55:20PM -0800, Andy Lutomirski wrote: > Eric Biggers found several crypto drivers that point scatterlists at > the stack. These drivers should never load on x86, but, for future > safety, make them depend on !VMAP_STACK. > > No -stable backport should be needed as no

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Mon, Dec 12, 2016 at 12:45:18PM -0600, Gary R Hook wrote: > On 12/12/2016 12:34 PM, Andy Lutomirski wrote: > > <...snip...> > > > > >I have a patch to make these depend on !VMAP_STACK. > > > >>drivers/crypto/ccp/ccp-crypto-aes-cmac.c:105,119,142 > >>

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

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 > > drivers/crypto/sahara.c:973,988 > > drivers/crypto/talitos.c:1910 > >

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

On Tue, Dec 13, 2016 at 12:05:19AM +0200, Michael S. Tsirkin wrote: > > > Sorry but it's too late for 4.10. It needed to have been in my > > tree before the merge window opened to make it for this cycle. > > Objections to me merging this? I'm preparing my tree right now. Sure feel free to merge

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

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(+) create mode 100644

[PATCH v2 1/2] Add crypto driver support for some MediaTek chips

This adds support for the MediaTek hardware accelerator on mt7623/mt2701/mt8521p SoC. This driver currently implement: - SHA1 and SHA2 family(HMAC) hash algorithms. - AES block cipher in CBC/ECB mode with 128/196/256 bits keys. Signed-off-by: Ryder Lee ---

[PATCH v2 0/2] Add MediaTek crypto accelerator driver

Hello, This adds support for the MediaTek hardware accelerator on some SoCs. This driver currently implement: - SHA1 and SHA2 family(HMAC) hash algorithms. - AES block cipher in CBC/ECB mode with 128/196/256 bits keys. Changes since v2: - use byteorder conversion macros and type identifiers

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

> > Subject: Re: [PATCH v6 2/2] crypto: add virtio-crypto driver > > 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

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

On Mon, Dec 12, 2016 at 2:28 PM, David Howells wrote: > Andy Lutomirski wrote: > >> +static const char zero_pad[16] = {0}; > > Isn't there a global page of zeros or something that we can share? Also, you > shouldn't explicitly initialise it so that it stays

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

On Mon, Dec 12, 2016 at 1:44 PM, Greg KH wrote: > On Mon, Dec 12, 2016 at 12:52:45PM -0800, Andy Lutomirski wrote: >> 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. Make

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

On Tue, Dec 13, 2016 at 12:01 AM, Andi Kleen wrote: > It would be nice if the network code could be converted to use siphash > for the secure sequence numbers. Right now it pulls in a lot of code > for bigger secure hashes just for that, which is a problem for tiny >

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

> Dozens of languages are already using this internally for their hash > tables. Some of the BSDs already use this in their kernels. SipHash is > a widely known high-speed solution to a widely known problem, and it's > time we catch-up. It would be nice if the network code could be converted to

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

Andy Lutomirski wrote: > +static const char zero_pad[16] = {0}; Isn't there a global page of zeros or something that we can share? Also, you shouldn't explicitly initialise it so that it stays in .bss. > - sg_set_buf(_out[1], pad, sizeof pad); > + sg_set_buf(_out[1],

[PATCH v3] 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 v6 2/2] crypto: add virtio-crypto driver

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 please merge the virtio-crypto driver for 4.10 if no other

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

On Mon, Dec 12, 2016 at 10:44 PM, Jason A. Donenfeld wrote: > #if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64 >switch (left) { >case 0: break; >case 1: b |= data[0]; break; >case 2: b |= get_unaligned_le16(data); break; >case

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

Hi Linus, > I guess you could try to just remove the "if (left)" test entirely, if > it is at least partly the mispredict. It should do the right thing > even with a zero count, and it might schedule the code better. Code > size _should_ be better with the byte mask model (which won't matter > in

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

On Sun, Dec 11, 2016 at 9:48 PM, Jason A. Donenfeld wrote: > I modified the test to hash data of size 0 through 7 repeatedly > 1 times, and benchmarked that a few times on a Skylake laptop. > The `load_unaligned_zeropad & bytemask_from_count` version was > consistently 7%

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

Hey Eric, Lots of good points; thanks for the review. Responses are inline below. On Mon, Dec 12, 2016 at 6:42 AM, Eric Biggers wrote: > Maybe add to the help text for CONFIG_TEST_HASH that it now tests siphash too? Good call. Will do. > This assumes the key and message

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

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 Biggers Signed-off-by: Andy

[PATCH] crypto: Make a few drivers depend on !VMAP_STACK

Eric Biggers found several crypto drivers that point scatterlists at the stack. These drivers should never load on x86, but, for future safety, make them depend on !VMAP_STACK. No -stable backport should be needed as no released kernel configuration should be affected. Reported-by: Eric Biggers

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

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 identical to some code that Eric Biggers suggested. Cc:

[PATCH] 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. Make the buffer static to fix it. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers Signed-off-by: Andy Lutomirski

[PATCH] 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 a static 16-byte buffer of zeros instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

[PATCH] crypto: arm64/aes: reimplement bit-sliced ARM/NEON implementation for arm64

This is a reimplementation of the NEON version of the bit-sliced AES algorithm. This code is heavily based on Andy Polyakov's OpenSSL version for ARM, which is also available in the kernel. This is an alternative for the existing NEON implementation for arm64 authored by me, which suffers from

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

Pan Bian wrote: > outlen = crypto_akcipher_maxsize(tfm); > output = kmalloc(outlen, GFP_KERNEL); > - if (!output) > + if (!output) { > + ret = -ENOMEM; > goto error_free_req; > + } This is preferred: + ret =

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

From: Mahipal Challa Add a driver for the ZIP engine found on Cavium ThunderX SOCs. The ZIP engine supports hardware accelerated compression and decompression. It includes 2 independent ZIP cores and supports: - DEFLATE compression and decompression (RFC 1951) - LZS

[RFC PATCH 2/3] crypto: zip - Wire-up Compression / decompression HW offload

From: Mahipal Challa This contains changes for adding compression/decompression h/w offload functionality for both DEFLATE and LZS. Signed-off-by: Mahipal Challa Signed-off-by: Vishnu Nair Signed-off-by: Jan Glauber

[RFC PATCH 3/3] crypto: zip - Add Compression/decompression statistics

From: Mahipal Challa Add statistics for compression/decompression hardware offload under debugfs. Signed-off-by: Mahipal Challa Signed-off-by: Vishnu Nair Signed-off-by: Jan Glauber ---

[RFC PATCH 0/3] Cavium ThunderX ZIP driver

Hi Herbert, this series adds support for hardware accelerated compression & decompression as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally for some time and would like to get feedback on the RFC to see if this goes into the right direction and to see if there are any

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

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 please merge the virtio-crypto driver for 4.10 if no other > comments? If so, Miachel pls ack and/or review the patch, then >