summaryrefslogtreecommitdiffstatshomepage
Commit message (Collapse)AuthorAgeFilesLines
* version: bumpv1.0.20200611Jason A. Donenfeld2020-06-112-2/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: remove stale suse supportJason A. Donenfeld2020-06-041-11/+3
| | | | | | | | The 42.x series is no longer supported, and the 15.2 kernel is getting a proper backport, so at the moment, we only care about supporting 15.1. Eventually we'll drop that too. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: bionic-hwe-5.0/disco kernel backported skb_reset_redirect and ipv6 flowJason A. Donenfeld2020-05-281-2/+4
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: mark per_cpu_load_addr as static for gcc-10Jason A. Donenfeld2020-05-281-0/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: work around broken centos8 kernelJason A. Donenfeld2020-05-281-0/+1
| | | | | | | RHEL needs to apply https://lore.kernel.org/patchwork/patch/974664/ before we can revert this monstrosity. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: ubuntu appears to have backported ipv6_dst_lookup_flowJason A. Donenfeld2020-05-281-1/+3
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: patch in UTS_UBUNTU_RELEASE_ABI for Ubuntu detectionJason A. Donenfeld2020-05-281-0/+1
| | | | | | | | This kind of thing really makes me queezy and upset, but there's little that can be done about such situations when dealing with Canonical's kernel. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: support fetching kernels for arbitrary URLsJason A. Donenfeld2020-05-281-1/+11
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: backport iptunnel_xmit to 3.11Jason A. Donenfeld2020-05-211-4/+11
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: narrow the breadth of iptunnel_xmit backportJason A. Donenfeld2020-05-211-1/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: widen breadth of prandom_u32_max backportJason A. Donenfeld2020-05-211-1/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: backport skb_scrub_packet to 3.11Jason A. Donenfeld2020-05-211-0/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: widen breadth of memzero_explicit backportJason A. Donenfeld2020-05-211-3/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: widen breadth of integer constantsJason A. Donenfeld2020-05-211-1/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: add extra fill in idt handler for newer binutilsJason A. Donenfeld2020-05-211-0/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: use cbuild gcc for avx512 exclusionJason A. Donenfeld2020-05-211-1/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: force 2MB pages for binutils 2.31Jason A. Donenfeld2020-05-211-0/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: patch kernels that rely on ancient makeJason A. Donenfeld2020-05-211-0/+1
| | | | | | | | Kernels without 9feeb638cde0 ("tools build: fix # escaping in .cmd files for future Make") face problems when building with more recent make, so patch these to avoid issues. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: remove -Werror in order to build ancient kernels betterJason A. Donenfeld2020-05-211-0/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: always use cbuild gcc rather than system gccJason A. Donenfeld2020-05-211-3/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* version: bumpv1.0.20200520Jason A. Donenfeld2020-05-202-2/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: support CentOS 8 explicitlyJason A. Donenfeld2020-05-201-4/+7
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: RHEL7 backported the skb hash renamingsJason A. Donenfeld2020-05-201-3/+3
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: ip6_dst_lookup_flow was backported to 4.14, 4.9, and 4.4Jason A. Donenfeld2020-05-201-1/+1
| | | | | | | Also remove the confusing 119/118 distinction from the Debian clause, which is no longer as important. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: backport renamed/missing skb hash membersJason A. Donenfeld2020-05-202-2/+15
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* noise: separate receive counter from send counterJason A. Donenfeld2020-05-195-54/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In "queueing: preserve flow hash across packet scrubbing", we were required to slightly increase the size of the receive replay counter to something still fairly small, but an increase nonetheless. It turns out that we can recoup some of the additional memory overhead by splitting up the prior union type into two distinct types. Before, we used the same "noise_counter" union for both sending and receiving, with sending just using a simple atomic64_t, while receiving used the full replay counter checker. This meant that most of the memory being allocated for the sending counter was being wasted. Since the old "noise_counter" type increased in size in the prior commit, now is a good time to split up that union type into a distinct "noise_replay_ counter" for receiving and a boring atomic64_t for sending, each using neither more nor less memory than required. Also, since sometimes the replay counter is accessed without necessitating additional accesses to the bitmap, we can reduce cache misses by hoisting the always-necessary lock above the bitmap in the struct layout. We also change a "noise_replay_counter" stack allocation to kmalloc in a -DDEBUG selftest so that KASAN doesn't trigger a stack frame warning. All and all, removing a bit of abstraction in this commit makes the code simpler and smaller, in addition to the motivating memory usage recuperation. For example, passing around raw "noise_symmetric_key" structs is something that really only makes sense within noise.c, in the one place where the sending and receiving keys can safely be thought of as the same type of object; subsequent to that, it's important that we uniformly access these through keypair->{sending,receiving}, where their distinct roles are always made explicit. So this patch allows us to draw that distinction clearly as well. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* queueing: preserve flow hash across packet scrubbingJason A. Donenfeld2020-05-194-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's important that we clear most header fields during encapsulation and decapsulation, because the packet is substantially changed, and we don't want any info leak or logic bug due to an accidental correlation. But, for encapsulation, it's wrong to clear skb->hash, since it's used by fq_codel and flow dissection in general. Without it, classification does not proceed as usual. This change might make it easier to estimate the number of innerflows by examining clustering of out of order packets, but this shouldn't open up anything that can't already be inferred otherwise (e.g. syn packet size inference), and fq_codel can be disabled anyway. Furthermore, it might be the case that the hash isn't used or queried at all until after wireguard transmits the encrypted UDP packet, which means skb->hash might still be zero at this point, and thus no hash taken over the inner packet data. In order to address this situation, we force a calculation of skb->hash before encrypting packet data. Of course this means that fq_codel might transmit packets slightly more out of order than usual. Toke did some testing on beefy machines with high quantities of parallel flows and found that increasing the reply-attack counter to 8192 takes care of the most pathological cases pretty well. Reported-by: Dave Taht <dave.taht@gmail.com> Reviewed-and-tested-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* noise: read preshared key while taking lockJason A. Donenfeld2020-05-191-1/+5
| | | | | | | | | | | | | | Prior we read the preshared key after dropping the handshake lock, which isn't an actual crypto issue if it races, but it's still not quite correct. So copy that part of the state into a temporary like we do with the rest of the handshake state variables. Then we can release the lock, operate on the temporary, and zero it out at the end of the function. In performance tests, the impact of this was entirely unnoticable, probably because those bytes are coming from the same cacheline as other things that are being copied out in the same manner. Reported-by: Matt Dunwoodie <ncon@noconroy.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: support RHEL 8 as 8.2, drop 8.1 supportJason A. Donenfeld2020-05-191-9/+4
| | | | | | | | This should help with 8.3 beta rolls being recognized as 8.1 instead of 8.2 quirks. Reported-by: Vladimir Benes <vbenes@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: add -fcommon for compiling ping with gcc-10Jason A. Donenfeld2020-05-191-1/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: use newer iproute2 for gcc-10Jason A. Donenfeld2020-05-081-1/+1
| | | | | | | | | | gcc-10 switched to defaulting to -fno-common, which broke iproute2-5.4. This was fixed in iproute-5.6, so switch to that. Because we're after a stable testing surface, we generally don't like to bump these unnecessarily, but in this case, being able to actually build is a basic necessity. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* version: bumpv1.0.20200506Jason A. Donenfeld2020-05-062-2/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* send/receive: use explicit unlikely branch instead of implicit coalescingJason A. Donenfeld2020-05-052-16/+12
| | | | | | | | | | | | | | | | | It's very unlikely that send will become true. It's nearly always false between 0 and 120 seconds of a session, and in most cases becomes true only between 120 and 121 seconds before becoming false again. So, unlikely(send) is clearly the right option here. What happened before was that we had this complex boolean expression with multiple likely and unlikely clauses nested. Since this is evaluated left-to-right anyway, the whole thing got converted to unlikely. So, we can clean this up to better represent what's going on. The generated code is the same. Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* selftests: initalize ipv6 members to NULL to squelch clang warningJason A. Donenfeld2020-05-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Without setting these to NULL, clang complains in certain configurations that have CONFIG_IPV6=n: In file included from drivers/net/wireguard/ratelimiter.c:223: drivers/net/wireguard/selftest/ratelimiter.c:173:34: error: variable 'skb6' is uninitialized when used here [-Werror,-Wuninitialized] ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count); ^~~~ drivers/net/wireguard/selftest/ratelimiter.c:123:29: note: initialize the variable 'skb6' to silence this warning struct sk_buff *skb4, *skb6; ^ = NULL drivers/net/wireguard/selftest/ratelimiter.c:173:40: error: variable 'hdr6' is uninitialized when used here [-Werror,-Wuninitialized] ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count); ^~~~ drivers/net/wireguard/selftest/ratelimiter.c:125:22: note: initialize the variable 'hdr6' to silence this warning struct ipv6hdr *hdr6; ^ We silence this warning by setting the variables to NULL as the warning suggests. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: Ubuntu 19.10 and 18.04-hwe backported skb_reset_redirectJason A. Donenfeld2020-05-041-2/+4
| | | | | Reported-by: Pascal Ernster <pascal.ernster@rub.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* send: cond_resched() when processing tx ringbuffersJason A. Donenfeld2020-05-041-0/+2
| | | | | | | | | | | | | Users with pathological hardware reported CPU stalls on CONFIG_ PREEMPT_VOLUNTARY=y, because the ringbuffers would stay full, meaning these workers would never terminate. That turned out not to be okay on systems without forced preemption. This commit adds a cond_resched() to the bottom of each loop iteration, so that these workers don't hog the core. We don't do this on encryption/decryption because the compat module here uses simd_relax, which already includes a call to schedule in preempt_enable. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* socket: remove errant restriction on looping to selfJason A. Donenfeld2020-05-042-15/+51
| | | | | | | | | | | | | | | | | | | | | | | It's already possible to create two different interfaces and loop packets between them. This has always been possible with tunnels in the kernel, and isn't specific to wireguard. Therefore, the networking stack already needs to deal with that. At the very least, the packet winds up exceeding the MTU and is discarded at that point. So, since this is already something that happens, there's no need to forbid the not very exceptional case of routing a packet back to the same interface; this loop is no different than others, and we shouldn't special case it, but rather rely on generic handling of loops in general. This also makes it easier to do interesting things with wireguard such as onion routing. At the same time, we add a selftest for this, ensuring that both onion routing works and infinite routing loops do not crash the kernel. We also add a test case for wireguard interfaces nesting packets and sending traffic between each other, as well as the loop in this case too. We make sure to send some throughput-heavy traffic for this use case, to stress out any possible recursion issues with the locks around workqueues. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: use normal kernel stack size on ppc64Jason A. Donenfeld2020-05-031-0/+1
| | | | | | | | | | | While at some point it might have made sense to be running these tests on ppc64 with 4k stacks, the kernel hasn't actually used 4k stacks on 64-bit powerpc in a long time, and more interesting things that we test don't really work when we deviate from the default (16k). So, we stop pushing our luck in this commit, and return to the default instead of the minimum. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: use bash instead of bc for HZ-->USEC calculationJason A. Donenfeld2020-05-031-5/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: detect Debian's backport of ip6_dst_lookup_flow into 4.19.118Jason A. Donenfeld2020-05-032-1/+5
| | | | | | Link: https://bugs.debian.org/959157 Reported-by: Luca Filipozzi <lfilipoz@debian.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* qemu: loop entropy adding until getrandom doesn't blockJason A. Donenfeld2020-05-031-1/+4
| | | | | | | Before the 256 was just a guess, which was made wrong by qemu 5.0, so instead actually query whether or not we're all set. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: timeconst.h is a generated artifactJason A. Donenfeld2020-04-301-1/+1
| | | | | | | | | | | Before we were trying to check for timeconst.h by looking in the kernel source directory. This isn't quite correct on configurations in which the object directory is separate from the kernel source directory, for example when using O="elsewhere" as a make option when building the kernel. The correct fix is to use $(CURDIR), which should point to where we want. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* version: bumpv1.0.20200429Jason A. Donenfeld2020-04-292-2/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: ip6_dst_lookup_flow was backported to 4.19.119Jason A. Donenfeld2020-04-291-1/+1
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: ip6_dst_lookup_flow was backported to 3.16.83Jason A. Donenfeld2020-04-291-5/+6
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* receive: use tunnel helpers for decapsulating ECN markingsToke Høiland-Jørgensen2020-04-282-16/+2
| | | | | | | | | | | | | | | | | WireGuard currently only propagates ECN markings on tunnel decap according to the old RFC3168 specification. However, the spec has since been updated in RFC6040 to recommend slightly different decapsulation semantics. This was implemented in the kernel as a set of common helpers for ECN decapsulation, so let's just switch over WireGuard to using those, so it can benefit from this enhancement and any future tweaks. We do not drop packets with invalid ECN marking combinations, because WireGuard is frequently used to work around broken ISPs, which could be doing that. Reported-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> Cc: Dave Taht <dave.taht@gmail.com> Cc: Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* version: bumpv1.0.20200426Jason A. Donenfeld2020-04-262-2/+2
| | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* compat: prefix icmp[v6]_ndo_send with __compatJason A. Donenfeld2020-04-261-4/+6
| | | | | | | | Some distros that backported icmp[v6]_ndo_send still try to build the compat module in some corner case circumstances, resulting in errors. Work around this with the usual __compat games. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* main: mark as in-treeJason A. Donenfeld2020-04-241-0/+1
| | | | | | We've been merged upstream and should no longer taint kernels. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* queueing: cleanup ptr_ring in error path of packet_queue_initJason A. Donenfeld2020-04-221-1/+3
| | | | | | | | | Prior, if the alloc_percpu of packet_percpu_multicore_worker_alloc failed, the previously allocated ptr_ring wouldn't be freed. This commit adds the missing call to ptr_ring_cleanup in the error case. Reported-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.