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>
No longer do we specify slack ourselves. Instead we need to add it
directly in the main scheduling.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
If /dev/urandom is a NOBUS RNG backdoor, like the infamous Dual_EC_DRBG,
then sending 4 bytes of raw RNG output over the wire directly might not
be such a great idea. This mitigates that vulnerability by, at some
point before the indices are generated, creating a random secret. Then,
for each session index, we simply run SipHash24 on an incrementing
counter.
This is probably overkill because /dev/urandom is probably not a
backdoored RNG, and itself already uses several rounds of SHA-1 for
mixing. If the kernel RNG is backdoored, there may very well be
bigger problems at play. Four bytes is also not so many bytes.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It may not be wise to directly publish the output of the CSPRNG, so we
run the output through a round of Blake2s first.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It turns out 4.1 is even more broken than expected. While both 4.1 and
4.2 need to jigger the sysctl nob temporarily, it turns out that in 4.1
it's looking in the wrong namespace for the nob value. So, we have to
account for the different namespace semantics in the different versions.
Super ugly. But, all this code goes away once we upstream.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is designed to work with a server that follows this:
struct sockaddr_un addr = {
.sun_family = AF_UNIX,
.sun_path = "/var/run/wireguard/wguserspace0.sock"
};
int fd, ret;
ssize_t len;
socklen_t socklen;
struct wgdevice *device;
fd = socket(AF_UNIX, SOCK_DGRAM, 0);
if (fd < 0)
exit(1);
if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0)
exit(1);
for (;;) {
/* First we look at how big the next message is, so we know how much to
* allocate. Note on BSD you can instead use ioctl(fd, FIONREAD, &len). */
len = recv(fd, NULL, 0, MSG_PEEK | MSG_TRUNC);
if (len < 0) {
handle_error();
continue;
}
/* Next we allocate a buffer for the received data. */
device = NULL;
if (len) {
device = malloc(len);
if (!device) {
handle_error();
continue;
}
}
/* Finally we receive the data, storing too the return address. */
socklen = sizeof(addr);
len = recvfrom(fd, device, len, 0, (struct sockaddr *)&addr, (socklen_t *)&socklen);
if (len < 0) {
handle_error();
free(device);
continue;
}
if (!len) { /* If len is zero, it's a "get" request, so we send our device back. */
device = get_current_wireguard_device(&len);
sendto(fd, device, len, 0, (struct sockaddr *)&addr, socklen);
} else { /* Otherwise, we just received a wgdevice, so we should "set" and send back the return status. */
ret = set_current_wireguard_device(device);
sendto(fd, &ret, sizeof(ret), 0, (struct sockaddr *)&addr, socklen);
free(device);
}
}
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
For timers in the hotpath, we don't want them to be rescheduled so
aggressively, and since they don't need to be that precise, we can set a
decent amount of slack.
With the persistent keepalive timer, we have something of a special
case. Since the timeout isn't fixed like the others, we don't want to
make it more often than the kernel ordinarily would. So, instead, we
make it a minimum.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
We sacrifice a little bit of precision here, but this avoids jockeying
around the timers for every packet, when we're sending in bundles anyway
to minimize cache misses.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Rather than only start sending the persistent keepalive packets when the
device first sends data, this changes it to send the packets immediately
on `ip link set up`. This makes things generally seem more stateless,
since the administrator does not have to manually ping the endpoint.
Of course, if you have a lot of peers and all of them have persistent
keepalive enabled, this could cause a lot of unwanted immediate traffic.
On the other hand, if all of those peers are at some point going to be
sending packets, this would happen anyway. I suppose the moral of the
story is that persistent keepalive is a feature really just for clients
behind NAT, not for servers, and it should be used sparingly, which is
why we've set it off by default in the first place.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It should never be the case that skb->head + skb->transport_header -
skb->data is greater than 2^16, but in case the kernel network stack
borks this at some point in the future, we don't want this to slyly
introduce a vulnerability into WireGuard.
Further, really smart compilers might be able to make deductions about
data_offset, and optimize accordingly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The padata free functions make reference to their parent workqueue, so
it's important that we wait to free the workqueue after the padata.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Per http://lists.openwall.net/netdev/2016/05/03/87 dev->trans_start has
been removed, and updates are now supposed to be handled with
netif_trans_update, which now updates the particular txqueue's
trans_start instead.
However, netdev_start_xmit already updates this member after calling
ndo_start_xmit, so the new netif_trans_update function smartly makes the
comment that for drivers that don't use LLTX, it's not neccessary to
call netif_trans_update.
Except we do use LLTX, so it would seem again that we do need to be
calling netif_trans_update. However, glancing at drivers like vxlan and
other similar virtual tunnels, this doesn't seem to be the case. I
suspect the reason is that we both also set IFF_NO_QUEUE, so we aren't
even using a txqueue for updating.
Thus, this patch removes updating of trans_start all together. I believe
this should be okay for older kernels too.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
With packets hitting multiple cores, a 64bit backtrack was too small.
This algorithm increases our backtrack to 1984bits.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld