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
> Her
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 c
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
---
drivers/crypto/cavium/zip/Makefile | 5 +-
drivers/crypto/cavium/
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 compression and decompression
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
---
drivers/crypto/cavium/zip/zip_deflate.c | 10 ++
drivers/crypto/cavium/zip/zip_inflate.c | 12 ++
driver
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 = -ENOMEM;
outlen = crypt
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 poor
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 support crypto
> accelerato
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
drivers/crypto/ccp/ccp-crypto-sha.c:95,109,124
drivers/crypto/ccp/ccp-crypto-aes-xts.c:162
driv
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
Signed-off-by: Andy Lutomirski
--
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
---
drivers/usb/wusbcore/cr
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: sta...@vger.ker
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
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 Lutomirski
---
Compile-teste
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 buffers are aligned to
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% slower.
>
> I the
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
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 the buffer static to fix it.
>
> Cc: sta...@vger.kernel.org # 4.9 only
> Reported-b
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 4: b |= get_unalig
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
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 any
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(&sg_out[1], pad, sizeof pad);
> + sg_set_buf(&sg_out[1], zero_pad, si
> 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 us
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
> kernels.
Indeed this would be
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 the buffer static to fix it.
>
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 in .bss.
This is a double-edged sword
>
> 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 2
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 for
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
---
drivers/crypto/Kconfig
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 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
diff --git a/Documen
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
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
> > drivers/crypto/qce/sha.c:325
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
> >>drivers/crypto/ccp/ccp-crypt
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
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 scatt
35 matches
Mail list logo
