Re: [PATCH net-next v8 28/28] net: WireGuard secure network tunnel

Hi Andrew, Thanks for the review. Comments and fix links are inline below. On Sun, Oct 21, 2018 at 12:47 AM Andrew Lunn wrote: > > > +#define choose_node(parent, key) > > \ > > + parent->bit[(key[parent->bit_at_a] >> parent->bit_at_b) & 1] > Thi

Re: [RFC PATCH v2 00/12] crypto: Adiantum support

Hey Eric, On Mon, Oct 22, 2018 at 12:23 AM Eric Biggers wrote: > I started a branch based on Zinc: Nice to see. I'm heading to bed in a second, so I'll give this a thorough read-through tomorrow, but some preliminary notes on your comments: > For Poly1305, for now I decided to just use the exis

Re: [RFC PATCH v2 00/12] crypto: Adiantum support

Hi Milan, On Sat, Oct 20, 2018 at 12:53 PM Milan Broz wrote: > Does it mean, that if Adiantum is based on Zinc, it can be no longer used > for FDE (dm-crypt)? IOW only file-based encryption is possible? No, don't worry. All I had in mind was the software implementations of chacha12 and so forth.

Re: [RFC PATCH v2 00/12] crypto: Adiantum support

Hello Eric, > As before, some of these patches conflict with the new "Zinc" crypto > library. But I don't know when Zinc will be merged, so for now I've > continued to base this patchset on the current 'cryptodev'. I'd appreciate it if you waited to merge this until you can rebase it on top of Z

[PATCH net-next v8 15/28] zinc: Poly1305 ARM and ARM64 implementations

0644 index ..f4f08ecffbf6 --- /dev/null +++ b/lib/zinc/poly1305/poly1305-arm-glue.c @@ -0,0 +1,140 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#include +#include + +asmlinkage void poly1305_init_arm(voi

[PATCH net-next v8 14/28] zinc: import Andy Polyakov's Poly1305 ARM and ARM64 implementations

ns to be the same as OpenSSL's commit 5bb1cd2292b388263a0cc05392bb99141212aa53 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski

[PATCH net-next v8 13/28] zinc: Poly1305 x86_64 implementation

00 768 836 560 784 888 572 800 838 588 816 884 604 832 894 598 848 946 612 864 896 628 880 942 644 896 952 608 912 1004616 928 954 634 944 1000646 960 1008646 976 1062 658 992 1012674

[PATCH net-next v8 10/28] zinc: ChaCha20 MIPS32r2 implementation

This MIPS32r2 implementation comes from René van Dorst and me and results in a nice speedup on the usual OpenWRT targets. Signed-off-by: Jason A. Donenfeld Signed-off-by: René van Dorst Co-developed-by: René van Dorst Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux

[PATCH net-next v8 11/28] zinc: Poly1305 generic C implementations and selftest

y1305.h b/include/zinc/poly1305.h new file mode 100644 index ..13fe0e50fc3c --- /dev/null +++ b/include/zinc/poly1305.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#ifndef _ZINC_POLY1

[PATCH net-next v8 12/28] zinc: import Andy Polyakov's Poly1305 x86_64 implementation

ns to be the same as OpenSSL's commit 4dfe4310c31c4483705991d9a798ce9be1ed1c68 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski C

[PATCH net-next v8 05/28] zinc: import Andy Polyakov's ChaCha20 x86_64 implementation

ns to be the same as OpenSSL's commit cded951378069a478391843f5f8653c1eb5128da Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski C

[PATCH net-next v8 09/28] zinc: ChaCha20 ARM and ARM64 implementations

s had an affect on any code existing in the kernel today. Signed-off-by: Jason A. Donenfeld Co-authored-by: Eric Biggers Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds

[PATCH net-next v8 04/28] zinc: ChaCha20 generic C implementation and selftest

This implements the ChaCha20 permutation as a single C statement, by way of the comma operator, which the compiler is able to simplify terrifically. Information: https://cr.yp.to/chacha.html Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc

[PATCH net-next v8 08/28] zinc: port Andy Polyakov's ChaCha20 ARM and ARM64 implementations

eon entry point. [ARM64 only] Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: kernel-harden...@lists.openwall.com Cc: linux-crypto@

[PATCH net-next v8 02/28] asm: simd context helper API

wild_simd_code(item); else boring_scalar_code(item); } The actual XSAVE happens during simd_use (and only on the first time), so that if the context is never actually used, no performance penalty is hit. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: T

[PATCH net-next v8 01/28] ARM: makefile: use ARMv3M mode for RiscPC

rtain cryptography code from working that uses instructions like umull. Fortunately there's also -march=armv3m that does support those, making it possible to continue assembling optimized cryptography routines for our beloved RiscPC. Signed-off-by: Jason A. Donenfeld --- Notes: This commi

[PATCH net-next v8 20/28] zinc: BLAKE2s x86_64 implementation

These implementations from Samuel Neves support AVX and AVX-512VL. Originally this used AVX-512F, but Skylake thermal throttling made AVX-512VL more attractive and possible to do with negligable difference. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Co-developed-by: Samuel

[PATCH net-next v8 19/28] zinc: BLAKE2s generic C implementation and selftest

s://blake2.net/ Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Co-developed-by: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: kernel-harden...@lists.openwall.com Cc: linux-crypto@vger.kernel.org --- in

[PATCH net-next v8 26/28] crypto: port ChaCha20 to Zinc

Now that ChaCha20 is in Zinc, we can have the crypto API code simply call into it. The crypto API expects to have a stored key per instance and independent nonces, so we follow suite and store the key and initialize the nonce independently. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc

[PATCH net-next v8 24/28] zinc: Curve25519 ARM implementation

ex-A7 | 49136 | 22395 | --- - | Cortex-A17 | 17326 |4983 | --- - Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Phi

[PATCH net-next v8 16/28] zinc: import Andy Polyakov's Poly1305 MIPS64 implementation

ns to be the same as OpenSSL's commit 947716c1872d210828122212d076d503ae68b928 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson

[PATCH net-next v8 27/28] security/keys: rewrite big_key crypto to use Zinc

complex custom page allocator that big_key really doesn't need. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: kernel-harden...@lists.openwall.com --- security/keys/Kco

[PATCH net-next v8 25/28] crypto: port Poly1305 to Zinc

Now that Poly1305 is in Zinc, we can have the crypto API code simply call into it. We have to do a little bit of book keeping here, because the crypto API receives the key in the first few calls to update. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc

[PATCH net-next v8 22/28] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Phi

[PATCH net-next v8 23/28] zinc: import Bernstein and Schwabe's Curve25519 ARM implementation

h, so that when we actually port it for use in the kernel in the subsequent commit, it's obvious what's changed in the process. This code originates from SUPERCOP 20180818, available at <https://bench.cr.yp.to/supercop.html>. Signed-off-by: Jason A. Donenfeld Cc: Russell Ki

[PATCH net-next v8 21/28] zinc: Curve25519 generic C implementations and selftest

*: https://github.com/project-everest/hacl-star The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto Information: https://cr.yp.to/ecdh.html Signed-off-by: Jason A. Donenfeld Cc: Karthikeyan Bhargavan Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH

[PATCH net-next v8 17/28] zinc: Poly1305 MIPS32r2 and MIPS64 implementations

function names have been renamed to fit kernel conventions. - A comment has been added. Signed-off-by: Jason A. Donenfeld Signed-off-by: René van Dorst Co-developed-by: René van Dorst Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: Samuel Neves Cc: Jean-Philippe

[PATCH net-next v8 06/28] zinc: ChaCha20 x86_64 implementation

1606688 800 1606714 816 1606736 832 1584660 848 1948688 864 1950714 880 1948736 896 1912688 912 2258718 928 2258744 944 2256768 960 2238692 976 2584718 992 2584 744 10082584770 Si

[PATCH net-next v8 07/28] zinc: import Andy Polyakov's ChaCha20 ARM and ARM64 implementations

ns to be the same as OpenSSL's commit 87cc649f30aaf69b351701875b9dac07c29ce8a2 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski

[PATCH net-next v8 03/28] zinc: introduce minimal cryptography library

f [6] https://cr.yp.to/mac.html [7] https://blake2.net/ [8] https://tools.ietf.org/html/rfc8439 [9] https://github.com/google/wycheproof Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: k

[PATCH net-next v8 00/28] WireGuard: Secure Network Tunnel

Changes v7->v8, along with who suggested it. - Implementations that fail the selftests are now disabled, after a warning is printed. This way users don't make wrong calculations, even in the face of a rather grave bug. - [Sultan Alsawaf] When assigni

Re: [PATCH 3/3] crypto: siphash - drop _aligned variants

Hi Ard, On Mon, Oct 8, 2018 at 11:16 PM Ard Biesheuvel wrote: > > On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > because the ordinary load/store instructions (ldr, ldrh, ldrb) can > tolerate any misalignment of the memory address. However, load/store > double and load/sto

Re: [PATCH net-next v7 25/28] crypto: port Poly1305 to Zinc

Hi Eric, On Tue, Oct 9, 2018 at 1:21 AM Eric Biggers wrote: > This crashes on very short inputs. crypto_poly1305_final() is missing: > > if (dctx->rem_key_bytes) > return -ENOKEY; Good catch, thanks. Queued for v8. Jason

[PATCH net-next v7 04/28] zinc: ChaCha20 generic C implementation and selftest

This implements the ChaCha20 permutation as a single C statement, by way of the comma operator, which the compiler is able to simplify terrifically. Information: https://cr.yp.to/chacha.html Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc

[PATCH net-next v7 05/28] zinc: import Andy Polyakov's ChaCha20 x86_64 implementation

ns to be the same as OpenSSL's commit cded951378069a478391843f5f8653c1eb5128da Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski C

[PATCH net-next v7 08/28] zinc: port Andy Polyakov's ChaCha20 ARM and ARM64 implementations

eon entry point. [ARM64 only] Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: kernel-harden...@lists.openwall.com Cc: linux-crypto@

[PATCH net-next v7 07/28] zinc: import Andy Polyakov's ChaCha20 ARM and ARM64 implementations

ns to be the same as OpenSSL's commit 87cc649f30aaf69b351701875b9dac07c29ce8a2 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski

[PATCH net-next v7 10/28] zinc: ChaCha20 MIPS32r2 implementation

This MIPS32r2 implementation comes from René van Dorst and me and results in a nice speedup on the usual OpenWRT targets. Signed-off-by: Jason A. Donenfeld Signed-off-by: René van Dorst Co-developed-by: René van Dorst Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux

[PATCH net-next v7 06/28] zinc: ChaCha20 x86_64 implementation

1606688 800 1606714 816 1606736 832 1584660 848 1948688 864 1950714 880 1948736 896 1912688 912 2258718 928 2258744 944 2256768 960 2238692 976 2584718 992 2584 744 10082584770 Si

[PATCH net-next v7 09/28] zinc: ChaCha20 ARM and ARM64 implementations

s had an affect on any code existing in the kernel today. Signed-off-by: Jason A. Donenfeld Co-authored-by: Eric Biggers Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds

[PATCH net-next v7 12/28] zinc: import Andy Polyakov's Poly1305 x86_64 implementation

ns to be the same as OpenSSL's commit 4dfe4310c31c4483705991d9a798ce9be1ed1c68 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski C

[PATCH net-next v7 13/28] zinc: Poly1305 x86_64 implementation

00 768 836 560 784 888 572 800 838 588 816 884 604 832 894 598 848 946 612 864 896 628 880 942 644 896 952 608 912 1004616 928 954 634 944 1000646 960 1008646 976 1062 658 992 1012674

[PATCH net-next v7 16/28] zinc: import Andy Polyakov's Poly1305 MIPS64 implementation

ns to be the same as OpenSSL's commit 947716c1872d210828122212d076d503ae68b928 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson

[PATCH net-next v7 11/28] zinc: Poly1305 generic C implementations and selftest

y1305.h b/include/zinc/poly1305.h new file mode 100644 index ..13fe0e50fc3c --- /dev/null +++ b/include/zinc/poly1305.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#ifndef _ZINC_POLY1

[PATCH net-next v7 19/28] zinc: BLAKE2s generic C implementation and selftest

s://blake2.net/ Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Co-developed-by: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torvalds Cc: kernel-harden...@lists.openwall.com Cc: linux-crypto@vger.kernel.org --- in

[PATCH net-next v7 21/28] zinc: Curve25519 generic C implementations and selftest

*: https://github.com/project-everest/hacl-star The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto Information: https://cr.yp.to/ecdh.html Signed-off-by: Jason A. Donenfeld Cc: Karthikeyan Bhargavan Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH

[PATCH net-next v7 20/28] zinc: BLAKE2s x86_64 implementation

These implementations from Samuel Neves support AVX and AVX-512VL. Originally this used AVX-512F, but Skylake thermal throttling made AVX-512VL more attractive and possible to do with negligable difference. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Co-developed-by: Samuel

[PATCH net-next v7 24/28] zinc: Curve25519 ARM implementation

ex-A7 | 49136 | 22395 | --- - | Cortex-A17 | 17326 |4983 | --- - Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Phi

[PATCH net-next v7 23/28] zinc: import Bernstein and Schwabe's Curve25519 ARM implementation

h, so that when we actually port it for use in the kernel in the subsequent commit, it's obvious what's changed in the process. This code originates from SUPERCOP 20180818, available at <https://bench.cr.yp.to/supercop.html>. Signed-off-by: Jason A. Donenfeld Cc: Russell Ki

[PATCH net-next v7 26/28] crypto: port ChaCha20 to Zinc

Now that ChaCha20 is in Zinc, we can have the crypto API code simply call into it. The crypto API expects to have a stored key per instance and independent nonces, so we follow suite and store the key and initialize the nonce independently. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc

[PATCH net-next v7 25/28] crypto: port Poly1305 to Zinc

Now that Poly1305 is in Zinc, we can have the crypto API code simply call into it. We have to do a little bit of book keeping here, because the crypto API receives the key in the first few calls to update. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc

[PATCH net-next v7 22/28] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Samuel Neves Cc: Jean-Phi

[PATCH net-next v7 17/28] zinc: Poly1305 MIPS32r2 and MIPS64 implementations

function names have been renamed to fit kernel conventions. - A comment has been added. Signed-off-by: Jason A. Donenfeld Signed-off-by: René van Dorst Co-developed-by: René van Dorst Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: Samuel Neves Cc: Jean-Philippe

[PATCH net-next v7 14/28] zinc: import Andy Polyakov's Poly1305 ARM and ARM64 implementations

ns to be the same as OpenSSL's commit 5bb1cd2292b388263a0cc05392bb99141212aa53 Signed-off-by: Jason A. Donenfeld Based-on-code-from: Andy Polyakov Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski

[PATCH net-next v7 15/28] zinc: Poly1305 ARM and ARM64 implementations

0644 index ..f4f08ecffbf6 --- /dev/null +++ b/lib/zinc/poly1305/poly1305-arm-glue.c @@ -0,0 +1,140 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#include +#include + +asmlinkage void poly1305_init_arm(voi

[PATCH net-next v7 03/28] zinc: introduce minimal cryptography library

a-20081128.pdf [6] https://cr.yp.to/mac.html [7] https://blake2.net/ [8] https://tools.ietf.org/html/rfc8439 [9] https://github.com/google/wycheproof Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Jean-Philippe Aumasson Cc: Andy Lutomirski Cc: Greg KH Cc: Andrew Morton Cc: Linus Torv

Re: [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation

Hey Dan, On Fri, Oct 05, 2018 at 03:05:38PM -, D. J. Bernstein wrote: > Of course, there are other ARM microarchitectures, and there are many > cases where different microarchitectures prefer different optimizations. > The kernel already has boot-time benchmarks for different optimizations > f

Re: [RFC PATCH 1/9] kernel: add support for patchable function pointers

Hey Andy, On Fri, Oct 5, 2018 at 7:44 PM Andy Lutomirski wrote: > I *think* the only change to Zinc per se would be that the calls like > chacha20_simd() would be static calls or patchable functions or > whatever we want to call them. And there could be a debugfs to > override the default select

Re: [RFC PATCH 1/9] kernel: add support for patchable function pointers

On Fri, Oct 5, 2018 at 7:29 PM Andy Lutomirski wrote: > (None of this is to say that I disagree with Jason, though -- I'm not > entirely convinced that this makes sense for Zinc. But maybe it can > be done in a way that makes everyone happy.) Zinc indeed will continue to push in the simpler and

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger wrote: > So we will have two competing crypo stacks in the kernel? > Having a lightweight crypto API is a good thing but I really don't like the > idea > of having zinc parallel to the existing crypto stack. No, as you've seen in this patchset, t

Re: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines

Hi Ard, On Fri, Oct 5, 2018 at 10:13 AM Ard Biesheuvel wrote: > At the moment, the Zinc library [1] is being proposed as a solution for that, > and while it does address the usability problems, it does a lot more than > that, and what we end up with is a lot less flexible than what we have now.

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Eric, On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers wrote: > It's not really about the name, though. It's actually about the whole way of > thinking about the submission. Is it a new special library with its own > things > going on, or is it just some crypto helper functions? It's really jus

Re: [PATCH net-next v6 11/23] zinc: import Andy Polyakov's Poly1305 ARM and ARM64 implementations

On Wed, Oct 3, 2018 at 4:08 PM Jason A. Donenfeld wrote: > for all of the other places, and so I the comment in the dev tree a The missing word between "I" and "the" is "extirpated".

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

On Wed, Oct 3, 2018 at 4:25 PM Ard Biesheuvel wrote: > >> On Wed, Oct 3, 2018 at 1:15 PM Ard Biesheuvel > >> wrote: > >>> > +config WIREGUARD > >>> > + tristate "WireGuard secure network tunnel" > >>> > + depends on NET && INET > >>> > >>> I think you need to add IPV6 here > >> > >>

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

Hi Ard, On Wed, Oct 3, 2018 at 1:15 PM Ard Biesheuvel wrote: > > +config WIREGUARD > > + tristate "WireGuard secure network tunnel" > > + depends on NET && INET > > I think you need to add IPV6 here Nope. Like much of the net tree, WireGuard can function on ipv6-less kernels. If you

Re: [PATCH net-next v6 11/23] zinc: import Andy Polyakov's Poly1305 ARM and ARM64 implementations

Hi Ard, On Wed, Oct 3, 2018 at 9:58 AM Ard Biesheuvel wrote: > >> it has changed. This awkward commit splitting has been requested for the > >> ARM[64] implementations in particular. > >> > > "This awkward commit splitting" Awkward in the sense that only those two commits are doing it, whereas t

Re: [PATCH net-next v6 21/23] crypto: port ChaCha20 to Zinc

Hi Eric, On Wed, Oct 3, 2018 at 7:56 AM Eric Biggers wrote: > Multiple threads may use the same tfm concurrently, so the tfm context must > not > be used to store per-request information such as the IV. Thanks, fixed for v7. Jason

Re: [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation

On Tue, Oct 2, 2018 at 6:59 PM Ard Biesheuvel wrote: > Could you elaborate on what qhasm is exactly? And, as with the other > patches, I would prefer it if we could have your changes as a separate > patch (although having the qhasm base would be preferred) By the way, as of a few minutes ago, if

Re: [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation

(+Dan,Peter in CC. Replying to: for context.) Hi Ard, On Tue, Oct 2, 2018 at 6:59 PM Ard Biesheuvel wrote: > Shouldn't this use the new simd abstraction as well? Yes, it probably should, thanks.

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel wrote: > Also, I still think the name Zinc (zinc is not crypto/) is needlessly > divisive and condescending, and unsaying it (in v2 and up) doesn't > really work on the Internet (especially since you are still repeating > it in your conference talk.) >

Re: [PATCH net-next v6 01/23] asm: simd context helper API

On Sun, Sep 30, 2018 at 7:35 AM Andy Lutomirski wrote: > >>> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain > >>> about it): the use of typedef in new code is strongly discouraged. > >>> This policy predates my involvement, so perhaps Joe can elaborate on >

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Herbert, On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu wrote: > > I would also strongly prefer that all crypto work is taken through > > Herbert's tree, so we have a coherent view of it before it goes > > upstream. > > I agree. I don't have any problems with the zinc code living in > its own git

Re: [PATCH net-next v6 21/23] crypto: port ChaCha20 to Zinc

Hi Herbert, On Tue, Oct 2, 2018 at 5:26 AM Herbert Xu wrote: > Oh nice, so you did the conversion of the existing crypto code. > > I presume someone has done the numbers and verified that there > is no performance regression? > > If so it would be good to include those numbers somewhere in this >

Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation

Hi Herbert, On Tue, Oct 2, 2018 at 5:18 AM Herbert Xu wrote: > > sizeold new > > > > 0 62 52 > > What is the old column? Is it the existing x86-64 implementation > in the kernel or something else? This needs to be made clear in the > patch description. Goo

Re: [PATCH net-next v6 03/23] zinc: ChaCha20 generic C implementation and selftest

Hi Herbert, On Tue, Oct 2, 2018 at 5:15 AM Herbert Xu wrote: > I don't have any problems with this interface. > > However, I'm very unhappy about the fact that this adds another > copy of the chacha20 implementation to the kernel. Either this > is better than the one that we already have or it i

Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation

Hi Ard, On Fri, Sep 28, 2018 at 5:47 PM Ard Biesheuvel wrote: > > While this is CRYPTOGAMS code, the originating code for this happens to > > be the same as OpenSSL's commit cded951378069a478391843f5f8653c1eb5128da > > > > I'd still prefer the kernel side changes to be presented as a separate > f

Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation

Hi Borislav, On Sat, Sep 29, 2018 at 9:56 AM Borislav Petkov wrote: > Documentation/process/submitting-patches.rst > > section 12, first sentence. > > The SOB chain needs to clearly express the path of the patch from > author(s) to the upstream kernel. Thanks for the clarification. I've receive

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Ard, On Sat, Sep 29, 2018 at 8:16 AM Ard Biesheuvel wrote: > > You mean to say that since these nobs are def_bool y and are > > essentially "depends on ARM", then I should just straight up use > > CONFIG_ARM? I had thought about this, but figured this would make it > > easier to later make the

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

[+Willy] Hi Ard, On Fri, Sep 28, 2018 at 7:47 PM Ard Biesheuvel wrote: > > On 28 September 2018 at 07:46, Jason A. Donenfeld wrote: > > WireGuard is indeed quite opinionated in its primitive choices, but I > > don't think it'd be wise to apply the same design to Zi

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Ard, On Fri, Sep 28, 2018 at 6:02 PM Ard Biesheuvel wrote: > Please put comments like this below the --- git-notes is nice for this indeed. > Are these CONFIG_ symbols defined anywhere at this point? Yes, they're introduced in the first zinc commit. There's no git-blame on git.kernel.org, p

Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation

Hi Ard, On Fri, Sep 28, 2018 at 5:47 PM Ard Biesheuvel wrote: > Please drop this SOB line: SOB is not about (co-)authorship but about > who handled the patch on its way into mainline. The s-o-b line is about the DCoO, which is given here by both of us, with the code starting in a shared tree tha

Re: [PATCH net-next v6 03/23] zinc: ChaCha20 generic C implementation and selftest

Hi Ard, On Fri, Sep 28, 2018 at 5:40 PM Ard Biesheuvel wrote: > > +struct chacha20_ctx { > > + u32 constant[4]; > > + u32 key[8]; > > + u32 counter[4]; > > +} __aligned(32); > > + > > 32 *byte* alignment? Is that right? If this is for performance and it > actually helps, using _

Re: [PATCH net-next v6 05/23] zinc: import Andy Polyakov's ChaCha20 ARM and ARM64 implementations

Hi Ard, On Fri, Sep 28, 2018 at 5:49 PM Ard Biesheuvel wrote: > As I mentioned before, I'd prefer this to be based on the original .pl > but if I am the only one objecting to this, I guess I can live with > it. We're working on that, actually. It's not obvious when it'll be ready to ship -- perh

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

On Fri, Sep 28, 2018 at 5:01 PM Andrew Lunn wrote: > The namespace is more than just about the linker. I see an Opps stack > trace with wg_ symbols, i know i need to talk to Jason. Without any > prefix, i have to go digging into the code to find out who i need to > talk to. This is one reason why

Re: [PATCH net-next v6 01/23] asm: simd context helper API

On Fri, Sep 28, 2018 at 4:00 PM Ard Biesheuvel wrote: > > On 28 September 2018 at 15:59, Jason A. Donenfeld wrote: > > On Fri, Sep 28, 2018 at 3:58 PM Ard Biesheuvel > > wrote: > >> > >> On 28 September 2018 at 15:47, Jason A. Donenfeld wrote: > &g

Re: [PATCH net-next v6 01/23] asm: simd context helper API

On Fri, Sep 28, 2018 at 3:58 PM Ard Biesheuvel wrote: > > On 28 September 2018 at 15:47, Jason A. Donenfeld wrote: > > On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel > > wrote: > >> >> +typedef enum { > >> >> + HAVE_NO_SIMD =

Re: [PATCH net-next v6 01/23] asm: simd context helper API

On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel wrote: > >> +typedef enum { > >> + HAVE_NO_SIMD = 1 << 0, > >> + HAVE_FULL_SIMD = 1 << 1, > >> + HAVE_SIMD_IN_USE = 1 << 31 > >> +} simd_context_t; > >> + > > Oh, and another thing (and I'm surprised checkpatch.pl didn't complain >

Re: [PATCH net-next v6 01/23] asm: simd context helper API

On Fri, Sep 28, 2018 at 10:28 AM Ard Biesheuvel wrote: > Given that this patch applies to all architectures at once, it is > probably better to drop the unrelated reordering hunks to avoid > conflicts. Ack. Will retain order for v7. > > +static __must_check inline bool may_use_simd(void) > > +{

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

On Fri, Sep 28, 2018 at 9:52 AM Ard Biesheuvel wrote: > As I understood from someone who was at your Kernel Recipes talk, you > mentioned that it actually stands for 'zinc is not crypto/' (note the > slash) I mentioned this was in v1 but it wasn't taken as lightly as planned and was removed, so i

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Eric, On Fri, Sep 28, 2018 at 6:55 AM Eric Biggers wrote: > And you still haven't answered my question about adding a new algorithm that > is > useful to have in both APIs. You're proposing that in most cases the crypto > API > part will need to go through Herbert while the implementation w

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Eric, On Thu, Sep 27, 2018 at 06:17:27PM -0700, Eric Biggers wrote: > So, Zinc will simultaneously replace the current crypto implementations, *and* > be "orthogonal" and "separate" from all the crypto code currently maintained > by > Herbert? You can't have your cake and eat it too... The p

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

On Fri, Sep 28, 2018 at 12:37 AM Jason A. Donenfeld wrote: > Will do. v7 will include the wg_ prefix. $ nm *.o | while read a b c; do [[ $b == T ]] && echo $c; done | grep -v ^wg_ cleanup_module init_module Success.

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

Hi Andrew, Thanks for following up with this. On Thu, Sep 27, 2018 at 3:15 AM Andrew Lunn wrote: > I know you have been concentrating on the crypto code, so i'm not > expecting too many changes at the moment in the network code. I should be addressing things in parallel, actually, so I'm happy

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Eric, On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote: > Why is Herbert Xu's existing crypto tree being circumvented, especially for > future patches (the initial merge isn't quite as important as that's a > one-time > event)? I like being able to check out cryptodev to test upcoming cryp

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski wrote: > I would add another consideration: if you can get better latency with > negligible overhead (0.1%? 0.05%), then that might make sense too. For > example, it seems plausible that checking need_resched() every few blocks > adds basically no

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hey again Thomas, On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote: > > Hi Thomas, > > I'm trying to optimize this for crypto performance while still taking > into account preemption concerns. I'm having a bit of trouble figuring > out a way to determine numer

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Thomas, I'm trying to optimize this for crypto performance while still taking into account preemption concerns. I'm having a bit of trouble figuring out a way to determine numerically what the upper bounds for this stuff looks like. I'm sure I could pick a pretty sane number that's arguably oka

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Wed, Sep 26, 2018 at 5:52 PM Ard Biesheuvel wrote: > > On Wed, 26 Sep 2018 at 17:50, Jason A. Donenfeld wrote: > > > > On Wed, Sep 26, 2018 at 5:45 PM Jason A. Donenfeld wrote: > > > So what you have in mind is something like calling simd_relax() every > >

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Wed, Sep 26, 2018 at 7:37 PM Eric Biggers wrote: > Can you please stop accusing Ard of "filibustering" your patchset? Spending > too > long in non-preemptible code is a real problem even on non-RT systems. > syzkaller has been reporting bugs where the kernel spins too long without any > preem

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Wed, Sep 26, 2018 at 6:55 PM Ard Biesheuvel wrote: > Framing it as /needless/ complexity does not help at all. The changes > you are proposing are very useful, but nobody wants two crypto > subsystems with two different maintainers in the kernel, so I would > like to understand where this is go

<    1   2   3   4   5   6   7   >