--
Hello My name is Haneefa, i am Arab girl. Contact me back
i have something to tell you about
On Sun, Sep 29, 2019 at 7:42 PM Jason A. Donenfeld wrote:
>
> I had previously put quite some effort into the simd_get, simd_put,
> simd_relax mechanism, so that the simd state could be persisted during
> both several calls to the same function and within long loops like
> below, with simd_relax e
Hi Sebastian, Thomas,
Take a look at the below snippet from this patch.
I had previously put quite some effort into the simd_get, simd_put,
simd_relax mechanism, so that the simd state could be persisted during
both several calls to the same function and within long loops like
below, with simd_re
From: Yunfeng Ye
[ Upstream commit 24fbf7bad888767bed952f540ac963bc57e47e15 ]
There are two problems in sec_free_hw_sgl():
First, when sgl_current->next is valid, @hw_sgl will be freed in the
first loop, but it free again after the loop.
Second, sgl_current and sgl_current->next_sgl is not mat
Reimplement the library routines to perform chacha20poly1305 en/decryption
on scatterlists, without [ab]using the [deprecated] blkcipher interface,
which is rather heavyweight and does things we don't really need.
Instead, we use the sg_miter API in a novel and clever way, to iterate
over the scat
This switches WireGuard to use lib/crypto libraries instead of the
Zinc ones.
This patch is intended to be squashed at merge time, or it will break
bisection.
---
drivers/net/Kconfig | 6 +++---
drivers/net/wireguard/cookie.c | 4 ++--
drivers/net/wireguard/messages.h | 6 +++---
Taken from
https://git.zx2c4.com/WireGuard/commit/src?id=3120425f69003be287cb2d308f89c7a6a0335ff0
Reported-by: Bruno Wolff III
---
drivers/net/wireguard/netlink.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/w
Move the core Poly1305 transformation into a separate library in
lib/crypto so it can be used by other subsystems without going
through the entire crypto API. Also, expose the usual init, update
and final routines as library functions so that the transformation
can be invoked without going through
Implement the init/update/final Poly1305 library routines in the
accelerated SIMD driver for x86 so they are accessible to users of
the Poly1305 library interface.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/poly1305_glue.c | 60 +++-
crypto/Kconfig | 2 +
This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementation
for NEON authored by Andy Polyakov, and contributed by him to the OpenSSL
project. The file 'poly1305-armv4.pl' is taken straight from this upstream
GitHub repository [0] at commit ec55a08dc0244ce570c4fc7cade330c60798952f,
This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementation
for NEON authored by Andy Polyakov, and contributed by him to the OpenSSL
project. The file 'poly1305-armv8.pl' is taken straight from this upstream
GitHub repository [0] at commit ec55a08dc0244ce570c4fc7cade330c60798952f,
In order to use 128-bit integer arithmetic in C code, the architecture
needs to have declared support for it by setting ARCH_SUPPORTS_INT128,
and it requires a version of the toolchain that supports this at build
time. This is why all existing tests for ARCH_SUPPORTS_INT128 also test
whether __SIZE
Move the existing shared ChaCha code into lib/crypto, and at the
same time, split the support header into a public version, and an
internal version that is only intended for consumption by crypto
implementations.
Also, refactor the generic implementation so it only gets exposed as the
chacha_crypt
Expose the accelerated NEON ChaCha routine directly as a symbol
export so that users of the ChaCha library can use it directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig| 1 +
arch/arm64/crypto/chacha-neon-glue.c | 12
2 files changed, 13 insertions(+)
Wire the existing x86 SIMD ChaCha code into the new ChaCha library
interface.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/chacha_glue.c | 14 ++
crypto/Kconfig| 1 +
include/crypto/chacha.h | 9 +
3 files changed, 24 insertions(+)
diff --git a/a
From: "Jason A. Donenfeld"
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
From: "Jason A. Donenfeld"
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and is included here in raw form so that subsequent commits that
fix these up for the kernel can see how it has changed. This code does
have some entirely cosmetic formatting differences, adding
From: "Jason A. Donenfeld"
This ports the SUPERCOP implementation for usage in kernel space. In
addition to the usual header, macro, and style changes required for
kernel space, it makes a few small changes to the code:
- The stack alignment is relaxed to 16 bytes.
- Superfluous mov statemen
Expose the accelerated NEON ChaCha routine directly as a symbol
export so that users of the ChaCha library can use it directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig| 1 +
arch/arm/crypto/chacha-neon-glue.c | 19 +--
2 files changed, 18 insertions
From: "Jason A. Donenfeld"
This contains two formally verified C implementations of the Curve25519
scalar multiplication function, one for 32-bit systems, and one for
64-bit systems whose compiler supports efficient 128-bit integer types.
Not only are these implementations formally verified, but
From: "Jason A. Donenfeld"
The C implementation was originally based on Samuel Neves' public
domain reference implementation but has since been heavily modified
for the kernel. We're able to do compile-time optimizations by moving
some scaffolding around the final function into the header file.
From: "Jason A. Donenfeld"
This implementation is the fastest available x86_64 implementation, and
unlike Sandy2x, it doesn't requie use of the floating point registers at
all. Instead it makes use of BMI2 and ADX, available on recent
microarchitectures. The implementation was written by Armando
This is a follow-up to 'crypto: wireguard using the existing crypto API'.
Linus has made it abundantly clear that using the abstract AEAD interface
is not acceptable for instantiating a transformation that is known at compile
time, so I will abandon that approach for the time being. If anyone turns
From: Yunfeng Ye
[ Upstream commit 24fbf7bad888767bed952f540ac963bc57e47e15 ]
There are two problems in sec_free_hw_sgl():
First, when sgl_current->next is valid, @hw_sgl will be freed in the
first loop, but it free again after the loop.
Second, sgl_current and sgl_current->next_sgl is not mat
From: Yunfeng Ye
[ Upstream commit 24fbf7bad888767bed952f540ac963bc57e47e15 ]
There are two problems in sec_free_hw_sgl():
First, when sgl_current->next is valid, @hw_sgl will be freed in the
first loop, but it free again after the loop.
Second, sgl_current and sgl_current->next_sgl is not mat
25 matches
Mail list logo
