On Wed, Sep 25, 2019 at 3:15 PM Linus Torvalds
wrote:
>
> I don't really have a dog in this fight, but on the whole I really
> liked the series. But this 18/18 raised my heckles, and I think I
> understand why it might raise the heckles of the wireguard people.
To be honest, I guess I _do_ have a
On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
wrote:
>
> Replace the chacha20poly1305() library calls with invocations of the
> RFC7539 AEAD, as implemented by the generic chacha20poly1305 template.
Honestly, the other patches look fine to me from what I've seen (with
the small note I had in a s
On Wed, 25 Sep 2019 at 23:01, Linus Torvalds
wrote:
>
> On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
> wrote:
> >
> > config ARCH_SUPPORTS_INT128
> > bool
> > + depends on !$(cc-option,-D__SIZEOF_INT128__=0)
>
> Hmm. Does this actually work?
>
> If that "depends on" now ends up b
On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
wrote:
>
> config ARCH_SUPPORTS_INT128
> bool
> + depends on !$(cc-option,-D__SIZEOF_INT128__=0)
Hmm. Does this actually work?
If that "depends on" now ends up being 'n', afaik the people who
_enable_ it just do a
select ARCH_
带开发瓢 +Ⅴ :ⓀⓕⓅ⒎⒎⒍⒏
---
drivers/net/Kconfig | 6 +++---
drivers/net/wireguard/cookie.c | 4 ++--
drivers/net/wireguard/messages.h | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c26aef673538..3bd4dc662392 100644
--- a/drivers/ne
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
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
Replace the chacha20poly1305() library calls with invocations of the
RFC7539 AEAD, as implemented by the generic chacha20poly1305 template.
For now, only synchronous AEADs are supported, but looking at the code,
it does not look terribly complicated to add support for async versions
of rfc7539(cha
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.
Add the usual init/update/final library routines for the Poly1305
keyed hash library. Since this will be the external interface of
the library, move the poly1305_core_* routines to the internal
header (and update the users to refer to it where needed)
Signed-off-by: Ard Biesheuvel
---
crypto/adi
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.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/poly1305_glue.c| 2 +-
crypto/Kconfig | 4 +
crypto/adiantu
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
Add a test case to the RFC7539 (non-ESP) test vector array that
exercises the newly added code path that may optimize away one
invocation of the shash when the assoclen is a multiple of the
Poly1305 block size.
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.h | 45
1 file
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,
Now that we have moved all the scratch buffers that must be allocated
on the heap out of the request context, we can move the request context
itself to the stack if we are instantiating a synchronous version of
the chacha20poly1305 transformation. This allows users of the AEAD to
allocate the reque
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,
The RFC7539 template uses an ahash Poly1305 transformation to implement
the authentication part of the algorithm. Since ahashes operate on
scatterlists only, this forces the RFC7539 driver to allocate scratch
buffers in the request context, to ensure that they are allocated from
the heap.
However,
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.
While at it, tidy up lib/crypto/Makefile a bit so we are ready for
some new arrivals.
This series proposes a way to incorporate WireGuard into the kernel
without relying on a wholesale replacement of the existing crypto
stack. It addresses two issues with the existing crypto API, i.e.,
the need to do a kmalloc() allocation for each request, and the fact
that it can only operate on s
In order to reduce the number of invocations of the RFC7539 template
into the Poly1305 driver, implement the new internal .update_from_sg
method that allows the driver to amortize the cost of FPU preserve/
restore sequences over a larger chunk of input.
Signed-off-by: Ard Biesheuvel
---
arch/x86
Add an internal method to the shash interface that permits templates
to invoke it with a scatterlist. Drivers implementing the shash
interface can opt into using this method, making it more straightforward
for templates to pass down data provided via scatterlists without forcing
the underlying shas
The mapped_{src,dst}_nents _returned_ from the dma_map_sg
call (which could be less than src/dst_nents) have to be
used to generate the job descriptors.
Signed-off-by: Iuliana Prodan
---
drivers/crypto/caam/caampkc.c | 54 ---
drivers/crypto/caam/caampkc.h
On Wed, Sep 25, 2019 at 03:34:01PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 24, 2019 at 07:12:40AM -0400, James Bottomley wrote:
> > I thought about that. The main problem is that most of the
> > construct/append functions use the header, and these are the functions
> > most useful to the TPM2B
On Tue, Sep 24, 2019 at 07:12:40AM -0400, James Bottomley wrote:
> I thought about that. The main problem is that most of the
> construct/append functions use the header, and these are the functions
> most useful to the TPM2B operation.
>
> The other thing that argues against this is that the TPM
On Tue, Sep 24, 2019 at 10:08:32AM +0200, Corentin Labbe wrote:
> This patch enables power management on the Security System.
> sun4i-ss now depends on PM because it simplify code and prevent some ifdef.
> But this is not a problem since arch maintainer want ARCH_SUNXI to
> depend on PM in the futu
26 matches
Mail list logo
