Age | Commit message (Collapse) | Author |
|
Our previous heuristic wasn't good enough, since CopperheadOS backported
CANARY_MASK without backporting get_random_u32, as Qualcomm did, so now
we just entirely rename all invocations of the function.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Qualcomm backported the get_random_u32 patch, even though kernel.org
didn't, which is a problem. They also backported another patch in the
same place which defines a new macro variable, so use this as a
differentiator.
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>
|
|
We do this after sending the keepalive anyway.
This is something of a regression, though, since before we'd cancel and
then send, but now we send and then cancel, so it introduces a potential
race, but hopefully that isn't too big of a deal.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
We reorganize this into also doing so on sending keepalives itself,
which means the state machine is much more consistent, even if this was
already implied.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
It's already done implicitly by recent kernels and it's not adding much
here.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
On systems with a 100hz tick, this causes handshakes to be retried in
slightly less than 5 seconds, which means they aren't sent at all. This
has the effect of the handshakes entirely stopping their retry cycle
until the next data packet is sent.
Reported-by: Andrew He <andrewhe@mit.edu>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: René van Dorst <opensource@vdorst.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
This avoids an O(n^2) traversal in favor of an O(n) one.
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>
|
|
Commit 5e3532e ("allowedips: use native endian on lookup") did two
things: It changed the endianness of (struct allowedips_node).bits to
native endian, and it moved the CIDR masking to the output code path
(walk_by_peer).
Adjust print_node in src/selftest/allowedips.h to deal with these
changes.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
The 3.10 kernel from Red Hat puts head_frag in between headers_start and
headers_end. This is triggered on the latest i40e driver. This results
in the packet being freed incorrectly, crashing the system. So, this
patch just ensures we don't zero any of the header bits.
The whole issue of zeroing header bits probably should be revisited
sometime somewhat soon.
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>
|
|
GCC 8.1 does not know about the invariant `0 <= ctx->num < POLY1305_BLOCK_SIZE`.
This results in a warning that `memcpy(ctx->data + num, inp, len);` may
overflow the `data` field, which is correct for arbitrary values of `num`.
To make the invariant explicit we ensure that `num` is in the required range.
An alternative would be to change `ctx->num` to a 4-bit bitfield at the point
of declaration.
This changes the code from `test ebp, ebp; jz end` to `and ebp, 15; jz
end`, which have identical performance characteristics.
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Suggested-by: Samuel Neves <sneves@dei.uc.pt>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Suggested-by: Samuel Neves <sneves@dei.uc.pt>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Also we satisfy lockdep here.
Suggested-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
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>
|
|
We're referencing these constants as one contiguous blob, so if there's
any merging that goes on with other constants elsewhere (such as the
kernel's current poly1305 implementation that we hope to replace), then
these will be reordered and have the wrong values.
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 might be that a particular route has a different MTU than the
interface, via `ip route add ... dev wg0 mtu 1281`, for example. In this
case, it's important that we don't accidently pad beyond the end of the
MTU. We accomplish that in this patch by carrying forward the MTU from
the dst if it exists. We also add a unit test for this issue.
Reported-by: Roman Mamedov <rm.wg@romanrm.net>
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>
|
|
Also add cselect optimization.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
It's faster and doesn't use the FPU.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Some Android 3.18 devices backport this macro.
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>
|