| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
No longer do we specify slack ourselves. Instead we need to add it
directly in the main scheduling.
|
| |
|
|
| |
To support OS X and Windows, we have to. Ugh.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It may not be wise to directly publish the output of the CSPRNG, so we
run the output through a round of Blake2s first.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
They have no permissions, so we're probably better off just creating a
socket file with the umask set, as we do in BSD.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
}
}
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We don't want people packaging these or even using these scripts, which
are only useful for limited development circumstances, so get rid of
them. More widespread development testing techniques still exist in
src/debug.mk and src/netns.sh
|
| |
|
|
| |
Suggested-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
| | |
|
Jason A. Donenfeld