Age | Commit message (Collapse) | Author |
|
This allows us to precompute the blake2s calls and save cycles, since
hchacha is fast.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
This fixes errors on big endian machines.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
It turns out some FrankenVMs disable AVX but keep AVX2, causing issues.
The crypto code now relies on having both AVX and AVX2 and the right
features.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
On MIPS, the IRQ and SoftIRQ handlers share the stack with whatever
kernel thread was interrupted. This means that Curve25519 can be
interrupted by, say, an ethernet controller, that then gets handled by a
SoftIRQ. If something like l2tp is being used, which uses quite a bit of
stack, then by the time the SoftIRQ handler gets to WireGuard code and
calls into the stack-heavy ChaPoly functions, our 8k stack is shot. In
other words, since Curve25519 is such a big consumer of stack, if it's
interrupted by anything else that uses a healthy amount of stack, then
disaster strikes.
The solution here is just to allocate using kmalloc. This is quite ugly,
and if performance becomes an issue, we might consider moving to a
kmem_cache allocator, or even having each peer keep its own preallocated
space. But for now, we'll try this.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
access helpers
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
This took hours of debugging. In some cases, the src and dst are
different for the last piece, so the incorrect code here resulted in
computing the poly1305 over the wrong data. This lead to packets being
unnecessarily dropped.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
The C standard states:
A declaration of a parameter as ``array of type'' shall be adjusted to ``qualified pointer to
type'', where the type qualifiers (if any) are those specified within the [ and ] of the
array type derivation. If the keyword static also appears within the [ and ] of the
array type derivation, then for each call to the function, the value of the corresponding
actual argument shall provide access to the first element of an array with at least as many
elements as specified by the size expression.
By changing void func(int array[4]) to void func(int array[static 4]),
we automatically get the compiler checking argument sizes for us, which
is quite nice.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|