| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can let userspace configure wireguard interfaces before the RNG is
fully initialized, since what we mostly care about is having good
randomness for ephemerals and xchacha nonces. By deferring the wait to
actually asking for the randomness, we give a lot more opportunity for
gathering entropy. This won't cover entropy for hash table secrets or
cookie secrets (which rotate anyway), but those have far less
catastrophic failure modes, so ensuring good randomness for elliptic
curve points and nonces should be sufficient.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Otherwise, we wind up not doing the right thing in the v6-only case, or
doing something totally borked when v4 and v6 are filled unevenly.
Reported-by: Roelf Wichertjes <contact@roelf.org>
|
|
|
|
|
|
|
|
| |
It's possible that get_random_bytes() will return bad randomness if it
hasn't been seeded. This patch makes configuration block until the RNG
is properly initialized.
Reference: http://www.openwall.com/lists/kernel-hardening/2017/06/02/2
|
|
|
|
|
|
|
|
| |
Replacing an entry that's already been replaced is something that could
happen when processing handshake messages in parallel, when starting up
multiple instances on the same machine.
Reported-by: Hubert Goisern <zweizweizwoelf@gmail.com>
|
| |
|
|
|
|
|
|
| |
It's different on different kernel versions, and we're not using it
anyway, so it's easiest to just get rid of it, rather than having
another ifdef maze.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It still is sort of experimental, I suppose, especially this part in the
udp_tunnel drop-in:
skb_orphan(skb);
sk_mem_reclaim(sk);
It seems like sometimes this won't do what we want, but it's hard to
diagnose exactly what's happening. In any case, nobody paid attention to
that warning anyway, so let's just get rid of it.
|
|
|
|
| |
IFNAMSIZ is 16, so this is two instructions on 64-bit.
|
|
|
|
|
|
|
| |
node_placement() is always given the address of a stack variable for rnode,
so there's no need to check if rnode is null.
Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com>
|
|
|
|
|
|
| |
padata disables it, but in order to use SIMD on ARM, we can't be
in an interrupt. We only do this on ARM since it adds jitter to the
performance.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 42dd5bd87e418275203dd6644b6b6b0cc310d4d9.
|
| |
|
| |
|
|
|
|
| |
Suggested-by: Sultan Alsawaf <sultanxda@gmail.com>
|
|
|
|
| |
Suggested-by: Peter Wu <peter@lekensteyn.nl>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While OpenResolv supports explicit ordering directives such as `-m` and
exclusivity directives such as `-x`, Debian's own resolvconf supports
none of this, instead using a hard coded list of interface name
templates for determining ordering. While trying to emulate `-x` is
difficult [*], we can at least try to mostly emulate `-m 0` by
masquerading as a `tun*` interface to resolvconf. Ugly, but it works.
[*] One heavy handed way of emulating `-x` would be something like:
# echo nameserver 8.8.8.8 > /etc/resolv.conf.wg0-exclusive
# mount --bind -o ro /etc/resolv.conf.wg0-exclusive /etc/resolv.conf
# rm -f /etc/resolv.conf.wg0-exclusive
This in practice works quite well, but is a bit heavy to put in a man
page. It also doesn't "stack" well. For example, if we simply run
`umount /etc/resolv.conf`, how do we know which resolv.conf entry we're
unmounting?
|
| |
|
| |
|
|
|
|
|
| |
Otherwise, traffic is sent with the IP address of a different interface,
and then packets don't actually get delivered.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The kernel API for this has changed a lot, so this test is important to
ensure our compat layer is doing the right thing.
|
| |
|
| |
|