On Wed, Sep 26, 2018 at 6:21 PM Andy Lutomirski wrote:
> Are, is what you’re saying that the Zinc chacha20 functions should call
> simd_relax() every n bytes automatically for some reasonable value of n? If
> so, seems sensible, except that some care might be needed to make sure they
> interac
Hi Ivan,
On Wed, Sep 26, 2018 at 6:00 PM Ivan Labáth wrote:
>
> On 25.09.2018 16:56, Jason A. Donenfeld wrote:
> > Extensive documentation and description of the protocol and
> > considerations, along with formal proofs of the cryptography, are>
> > avai
On Wed, Sep 26, 2018 at 5:52 PM Ard Biesheuvel
wrote:
> Nice one :-)
>
> This works for me (but perhaps add a comment as well)
Sure. Just a prototype; it'll be clean for v7.
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
> 4096 bytes or so?
That was actually pretty easy, putting together both of your suggestions:
static inline bool chacha20_arch(struct chacha20_ctx *state, u
On Wed, Sep 26, 2018 at 5:42 PM Ard Biesheuvel
wrote:
>
> On Wed, 26 Sep 2018 at 16:02, Ard Biesheuvel
> wrote:
> Actually, looking at the code again, the abstraction does appear to be
> fine, it is just the chacha20 code that does not make use of it.
So what you have in mind is something like
On Wed, Sep 26, 2018 at 4:02 PM Ard Biesheuvel
wrote:
> I don't think it makes sense to keep
> it simple now and add the complexity later (and the same concern
> applies to async support btw).
Ugh, no. I don't want to add needless complexity, period. Zinc is
synchronous, not asynchronous. It prov
On Wed, Sep 26, 2018 at 4:36 PM Andrew Lunn wrote:
> The wireguard interface claims it is GSO capable. This means the
> network stack will pass it big chunks of data and leave it to the
> network interface to perform the segmentation into 1500 byte MTU
> frames on the wire. I've not looked at how
Hi Ard,
On Wed, Sep 26, 2018 at 10:59 AM Ard Biesheuvel
wrote:
> > +static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
> > +const u8 *src, size_t len,
> > +simd_context_t *simd_context)
> > +{
> > +#if defined(CONF
On Tue, Sep 25, 2018 at 11:02 PM Joe Perches wrote:
> Then you should change the CONFIG_ZINC_DEBUG option too.
Yes, indeed.
Hi Joe,
On Tue, Sep 25, 2018 at 10:21 PM Joe Perches wrote:
> I'd still prefer as all these are effectively
> debugging output that you convert the pr_info
> uses pr_debug and so avoid using pr_fmt altogether.
I started to write back, "sure no problem, this will be in v7," but
then I gave it a c
Hi Joe,
On Tue, Sep 25, 2018 at 10:05 PM Joe Perches wrote:
> As far as I can tell, zinc doesn't use pr_err, just
> pr_info
Yes, pr_info, not pr_err. Apologies for my imprecision. But the
distinction does not matter at all, since they both use pr_fmt in
exactly the same way, which is sufficient
On Tue, Sep 25, 2018 at 10:00 PM Andy Lutomirski wrote:
> > On Sep 25, 2018, at 12:43 PM, Jason A. Donenfeld wrote:
> >
> >> On Tue, Sep 25, 2018 at 8:33 PM Joe Perches wrote:
> >> I think the -Dpr_fmt is especially odd and not
> >> really acceptable a
On Tue, Sep 25, 2018 at 8:33 PM Joe Perches wrote:
> I think the -Dpr_fmt is especially odd and not
> really acceptable as it not used anywhere else
> in the kernel.
There are about 2000 cases in the kernel of the same '#define
pr_fmt...' being pasted into the top of the file, which seems a bit
c
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: Thoma
code from L1 cache -- particularly on ARM11 chips -- and
so in certain circumstances it can actually be faster. However, it wasn't
found that this had an affect on any code existing in the kernel today.
Signed-off-by: Jason A. Donenfeld
Co-authored-by: Eric Biggers
Cc: Samuel Neves
Cc:
eon entry point. [ARM64 only]
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
lib/zinc/chacha20/chacha20-arm-cryptogams.S | 367 +-
lib/zinc/chacha20
clude/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_POLY1305_H
+#define _ZINC_POLY1305_H
+
+#include
+#include
+
+enum poly1305_lengths {
+ POLY1305_BLOCK_SIZE
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: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe
2
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 1062658
992 1012674
10081058690
Signed-off-by: Jason
been renamed to fit kernel conventions.
- Labels have been renamed to fit kernel conventions.
- The neon code can jump to the scalar code when it makes sense to do
so.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Russell
RM[64] implementations in particular.
While this is CRYPTOGAMS code, the originating code for this happens to
be the same as OpenSSL's commit 5bb1cd2292b388263a0cc05392bb99141212aa53
Signed-off-by: Jason A. Donenfeld
Based-on-code-from: Andy Polyakov
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: G
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
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
complex custom page allocator that big_key really doesn't
need.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Eric Biggers
Cc: David Howells
---
security/keys/Kconfig | 4 +-
secu
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc:
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
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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc:
*:
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: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Karthikeyan Bhargavan
RM[64] implementations in particular.
While this is CRYPTOGAMS code, the originating code for this happens to
be the same as OpenSSL's commit 87cc649f30aaf69b351701875b9dac07c29ce8a2
Signed-off-by: Jason A. Donenfeld
Based-on-code-from: Andy Polyakov
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: G
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Co-developed-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
include/zinc/blake2s.h | 58 +
lib/zinc/Kconfig|3 +
lib/zinc/Makefile |3 +
lib/zi
y1305/poly1305-mips-glue.h
b/lib/zinc/poly1305/poly1305-mips-glue.h
new file mode 100644
index ..eb38cd5a75ae
--- /dev/null
+++ b/lib/zinc/poly1305/poly1305-mips-glue.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * Copyright (C) 2015-2018 Jason A. Donenfeld . All R
2584744
10082584770
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Co-developed-by: Samuel Neves
Based-on-code-from: Andy Polyakov
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: Ingo Molna
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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe
o/snuffle/xsalsa-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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
Changes v5->v6, along with who suggested it.
- [Eric Biggers] Cleaner and more efficient blake2s_final function.
- [Eric Biggers] Remove modulo trick that was working around a gcc 8.1 bug.
- [Eric Biggers] Use crypto_xor_cpy to avoid a memmove in c
Hey Ard,
On Tue, Sep 25, 2018 at 12:25 PM Ard Biesheuvel
wrote:
> Kees is currently dealing with VLA uses in crypto API skcipher
> invocations [0] that don't benefit from its async capabilities nor
> from the runtime resolution of cipher name strings, given that they
> always select the same one.
Hey Arnd,
On Tue, Sep 25, 2018 at 9:18 AM Arnd Bergmann wrote:
> I think I misread your earlier sentence and thought you had said the
> exact opposite.
>
> For confirmation, I've downloaded your git tree and built it with my
> collection of compilers (gcc-4.6 through 8.1) and tried building it
>
Hi Ard,
On Fri, Sep 21, 2018 at 6:30 AM Ard Biesheuvel
wrote:
> Did any of the fuzzing/testing you mention in the cover letter occur
> on the kernel versions of these algorithms?
Yes, of course.
Jason
Hi Andy,
On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski wrote:
> At the risk on suggesting something awful: on x86_64, since we turn
> preemption off for simd, it wouldn’t be *completely* insane to do the crypto
> on the irq stack. It would look like:
>
> kernel_fpu_call(func, arg);
>
> And th
Hi Andrew,
On Fri, Sep 21, 2018 at 5:13 AM Andrew Lunn wrote:
> Do you any stack usage information?
>
> A VPN can be at the bottom of some deep stack calls. Swap on NFS over
> the VPN? If you have one frame of 1K, you might be O.K. But if you
> have a few of these, i can see there might be issues
Hi Ard,
On Thu, Sep 20, 2018 at 5:42 PM Ard Biesheuvel
wrote:
> Apologies for not spotting these before:
>
> > +ccflags-y := -O3
>
> -O3 optimization has been problematic in the past, at least on x86 but
> I think on other architectures as well. Please stick with -O2.
Fixed up for v6.
>
> > +cc
Hey Arnd,
On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
> Right, if you hit a stack requirement like this, it's usually the compiler
> doing something bad, not just using too much stack but also generating
> rather slow object code in the process. It's better to fix the bug by
> optimizing
Hi Paul,
Thanks a bunch for the review.
On Tue, Sep 18, 2018 at 10:25 PM Paul Burton wrote:
> Should this be .set reorder?
Nice catch. Fixed here:
https://git.zx2c4.com/WireGuard/commit/?id=23d97fc333cf85dd07445a9d21a28cbef47c553c
But then...
> Even better - could we not just place the addiu b
On Wed, Sep 19, 2018 at 1:50 PM Jason A. Donenfeld wrote:
>
> On Wed, Sep 19, 2018 at 6:19 AM Andy Lutomirski wrote:
> > Can you not uglify the code a bit by using normal (non-compound) liberals
> > as described in the response to that email?
>
> I can define a bunc
On Wed, Sep 19, 2018 at 6:19 AM Andy Lutomirski wrote:
> Can you not uglify the code a bit by using normal (non-compound) liberals as
> described in the response to that email?
I can define a bunch of variables, and then string them all together
in an array at the end. This is a bit ugly and les
Hi Thomas,
On Wed, Sep 19, 2018 at 8:13 AM Thomas Gleixner wrote:
> Subset? Not really. Both MIT and BSD3-Clause are GPL2.0 compatible
> licenses. And if your intention is to have those files MIT/BSD only, yes
> then the single license identifier is the right thing. If you want it dual
> licensed
Hi Thomas,
On Wed, Sep 19, 2018 at 12:30 AM Thomas Gleixner wrote:
> I'm a bit confused by this SOB chain. So above you write that it's from
> Andy Polakovs implementation and Samuel did the changes. But here it seems
> you are the main author. If Samuel just did some modifications then you
> wan
Hi Andrew,
On Wed, Sep 19, 2018 at 1:34 AM Andrew Lunn wrote:
> I see this BUG_ON() is still here. It really needs to be removed. It
> does not look like you need to crash the kernel here. Can you add in a
> test of len >= 128, do a WARN and then return. I think you then leak
> some memory, but i
On Wed, Sep 19, 2018 at 3:08 AM Eric Biggers wrote:
> Does this consistently perform as well as an implementation that organizes the
> operations such that the quarterrounds for all columns/diagonals are
> interleaved? As-is, there are tight dependencies in QUARTER_ROUND() (as well
> as
> in the
On Wed, Sep 19, 2018 at 3:39 AM Jason A. Donenfeld wrote:
>
> > > + const size_t num = ctx->num % POLY1305_BLOCK_SIZE;
> > 0 <= ctx->num < POLY1305_BLOCK_SIZE, so no need to mod by
> > POLY1305_BLOCK_SIZE.
> > > + size_t num = ctx->num
> > + const size_t num = ctx->num % POLY1305_BLOCK_SIZE;
> 0 <= ctx->num < POLY1305_BLOCK_SIZE, so no need to mod by POLY1305_BLOCK_SIZE.
> > + size_t num = ctx->num % POLY1305_BLOCK_SIZE;
> Same here.
I know, but I was having a hard time convincing gcc-8 of that
invariant, and it was warn
On Wed, Sep 19, 2018 at 2:50 AM Eric Biggers wrote:
> Hardcoding the 'input' array to 600 bytes forces the full amount of space to
> be
> reserved in the kernel image for every test vector. Also, if anyone adds a
> longer test vector they will need to remember to increase the value.
>
> It shoul
Hey Eric,
On Wed, Sep 19, 2018 at 2:41 AM Eric Biggers wrote:
> This buffer is 4 times too long.
Nice catch.
> Or how about something much simpler:
>
> static inline void blake2s_final(struct blake2s_state *state, u8 *out,
> const size_t outlen)
> {
> #ifdef DEB
Hi Eric,
On Wed, Sep 19, 2018 at 12:55 AM Eric Biggers wrote:
> This will compute the wrong digest if called with simd_context=HAVE_FULL_SIMD
> and then later with simd_context=HAVE_NO_SIMD, since poly1305_blocks_neon()
> converts the accumulator from base 32 to base 26, whereas
> poly1305_block
Hi Ard,
On Tue, Sep 18, 2018 at 11:28:50AM -0700, Ard Biesheuvel wrote:
> On 18 September 2018 at 09:16, Jason A. Donenfeld wrote:
> > - While I initially wasn't going to do this for the initial
> > patchset, it was just so simple to do: now there's a nosimd
>
Hi Ard,
On Tue, Sep 18, 2018 at 11:53:11AM -0700, Ard Biesheuvel wrote:
> On 17 September 2018 at 08:52, Jason A. Donenfeld wrote:
> > Hi Ard,
> >
>
> Given that you show no interest whatsoever in gaining an understanding
> of the underlying requirements that we have to
Hi David,
On Tue, Sep 18, 2018 at 06:01:47PM +0100, David Howells wrote:
> Jason A. Donenfeld wrote:
>
> > A while back, I noticed that the crypto and crypto API usage in big_keys
> > were entirely broken in multiple ways, so I rewrote it. Now, I'm
> > rewriting
Hi Ard,
On Tue, Sep 18, 2018 at 6:06 PM Ard Biesheuvel
wrote:
> as long as we have data that supports the claim that it
> is actually faster on hardware people care about.
Seems reasonable. I'll next be turning my attention back to ARM
performance. I'll try to gather some numbers. Expect data a
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
include/zinc/blake2s.h | 95 ++
lib/zinc/Kconfig|3 +
lib/zinc/Makefile |3 +
lib/zinc/blake2s/blake2s.c | 301
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
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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc:
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc:
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
complex custom page allocator that big_key really doesn't
need.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Eric Biggers
Cc: David Howells
---
security/keys/Kconfig | 4 +-
secu
*:
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: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Karthikeyan Bhargavan
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
Cc: Andy Lutomirski
Cc
names have been renamed to fit kernel conventions.
- A comment has been added.
No changes have been made to the actual instructions.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: René van Dorst
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc
616
928 954 634
944 1000646
960 1008646
976 1062658
992 1012674
1008 1058 690
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: I
ldp x29,x30,[sp],#96
+.Labort_neon:
ret
+ENDPROC(chacha20_neon)
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
--
,[x1] // write result
ret
+ENDPROC(poly1305_emit_neon)
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
lib/zinc/Makefile
clude/zinc/poly1305.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: MIT
+ *
+ * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights
Reserved.
+ */
+
+#ifndef _ZINC_POLY1305_H
+#define _ZINC_POLY1305_H
+
+#include
+#include
+
+enum poly1305_lengths {
+ POLY1305_BLOCK_SIZE
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
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Ralf Baechle
Cc: Paul
714
880 1948736
896 1912688
912 2258718
928 2258744
944 2256768
960 2238692
976 2584718
992 2584744
1008 2584 770
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe
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: Thoma
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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe
v5 has the most comprehensive set of changes yet, and I think should
finally address all of the relevant issues brought up on the mailing
list. In particular, this feedback has come from:
- Andy Lutomirski
- Eric Biggers
- Ard Biesheuvel
- Kevin Easton
- Andrew Lunn
- Martin Willi
Cha
o/snuffle/xsalsa-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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
Hi Herbert,
On Tue, Sep 18, 2018 at 6:21 AM Herbert Xu wrote:
> That may be your view but from what I've read Ard has been very
> constructive in pointing out issues in your submission.
> Please keep in mind that this is a large project that has to support
> multiple users on one hand (not just W
Hey Andy,
On Mon, Sep 17, 2018 at 6:18 PM Andy Lutomirski wrote:
> I think it’s fine for later. It’s potentially useful for benchmarking and
> debugging.
I went ahead and added it anyway in the end. It was really quite easy
to do, and it sets a good template for future primitives that are
added
On Mon, Sep 17, 2018 at 4:54 PM Andy Lutomirski wrote:
> be nice, but if the authors of that assembly are convinced it should be
> replaced, then this step is optional IMO.
I think this actually makes the patchset and maintenance of it a lot
more confusing, so I'm going to abort doing this. I'd
On Mon, Sep 17, 2018 at 6:06 PM Andy Lutomirski wrote:
> #ifdef CONFIG_X86_64
> #include "whatever"
> #endif
>
> It seems a more obfuscated than needed to put the equivalent of that
> into the Makefile, and I don't think people really like searching
> through the Makefile to figure out why the cod
On Mon, Sep 17, 2018 at 6:14 PM Andy Lutomirski wrote:
> Indeed. What I'm saying is that you shouldn't refactor it this way
> because it will be slow. I agree it would be conceptually nice to be
> able to blacklist a chacha20_x86_64 module to disable the asm, but I
> think it would be very hard
Hi Ard,
On Mon, Sep 17, 2018 at 7:26 AM Ard Biesheuvel
wrote:
> OK, so let me summarize my remaining concerns as well. I may be a bit
> more finicky than Andy, though.
Yes, and generally hostile to this whole initiative since the
beginning. But I am very grateful for your reviews nonetheless, an
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
> I think the module organization needs to change. It needs to be possible to
> have chacha20 built in but AES or whatever as a module.
Okay, I'll do that for v5.
> I might have agreed before Spectre :(. Unfortunately, unless we do some
>
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
> > * (Nit) The GCC command line -include'd .h files contain variable and
> > function definitions so they are actually .c files.
>
> Hmm. I would suggest just getting rid of the -include magic entirely. The
> resulting ifdef will be more co
On Mon, Sep 17, 2018 at 4:56 PM Andy Lutomirski wrote:
> Would you accept Ard’s (and/or Eric Biggers’, perhaps, as an alternative)?
> Or, if you really want Herbert’s review, can you ask him to review it? (Hi
> Herbert!)
Preferably Eric's.
On Mon, Sep 17, 2018 at 4:54 PM Andy Lutomirski wrote:
> Ard, what do you think? I think it would
> be nice, but if the authors of that assembly are convinced it should be
> replaced, then this step is optional IMO.
I just spent several hours reworking everything for ChaCha. That was
the easy o
Hey Andy,
Thanks a lot for your feedback.
On Mon, Sep 17, 2018 at 6:09 AM Andy Lutomirski wrote:
> 1. Zinc conflates the addition of a new API with the replacement of
> some algorithm implementations. This is problematic. Look at the
> recent benchmarks of ipsec before and after this series.
Hey Martin,
Thanks for running these and pointing this out. I've replicated the
results with tcrypt and fixed some issues, and the next patch series
should be a lot closer to what you'd expect, instead of the regression
you noticed. Most of the slowdown happened as a result of over-eager
XSAVEs, w
Greetings Mr. Ro Bot,
Another one of your robot friends also caught this, and the offending
code has been removed for v5.
Thanks for botting,
Jason
Hey again Ro,
> 32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if
> CPU_V7
This shouldn't have ever been there anyway. Fixed now for v5.
Thanks,
Jason
Hi Mr. Ro Bot,
Looks like this is related to stack frames with KASAN. I've fixed this for v5.
Thanks,
Jason
Hi Mr. Ro Bot,
On Sun, Sep 16, 2018 at 1:14 AM kbuild test robot wrote:
>crypto/chacha20_zinc.o: In function `crypto_chacha20_crypt':
> >> crypto/chacha20_zinc.c:55: undefined reference to `chacha20'
Looks like my Kconfig change didn't get squashed in as intended. Fixed for v5.
Thanks,
Jaso
Hi Mr. Ro Bot,
On Sun, Sep 16, 2018 at 12:19 AM kbuild test robot wrote:
>drivers/net/wireguard/send.c: In function 'packet_encrypt_worker':
> >> drivers/net/wireguard/send.c:320:1: warning: the frame size of 1136 bytes
> >> is larger than 1024 bytes [-Wframe-larger-than=]
> }
Thanks, f
On Fri, Sep 14, 2018 at 7:38 PM Ard Biesheuvel
wrote:
> so could we please bring that discussion to a close before we drop the ARM
> code?
My understanding is that either these will find their way up to AndyP
and then back down here, or Eric or you will augment the .S in this
patch at a later da
On Fri, Sep 14, 2018 at 7:40 PM Ard Biesheuvel
wrote:
> > - Move away from makefile ifdef maze and instead prefer kconfig values,
> > which also makes the design a bit more modular too, which could help
> > in the future.
>
> Could you elaborate on this? From the patches, it is not clear
Hi Ard,
On Fri, Sep 14, 2018 at 7:27 PM Ard Biesheuvel
wrote:
> As I asked in response to v3, could we please have this as a separate
> patch on top? The diff below is corrupted.
I had played with that originally, but thought it made things actually
harder to review, whereas here you have the ch
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
include/zinc/blake2s.h | 101 ++
lib/zinc/Kconfig|4 +
lib/zinc/Makefile |4 +
lib/zinc/blake2s/blake2s.c | 274
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc:
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: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc:
201 - 300 of 660 matches
Mail list logo
