源代码提交(23)
-
由 Jason A. Donenfeld 创作于
If we're being delivered packets from multiple CPUs so quickly that the ring lock is contended for CPU tries, then it's safe to assume that the queue is near capacity anyway, so just drop the packet rather than spinning. This helps deal with multicore DoS that can interfere with data path performance. It _still_ does not completely fix the issue, but it again chips away at it. Reported-by:
Streun Fabio <fstreun@student.ethz.ch> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
e44c78cb -
由 Gustavo A. R. Silva 创作于
Use 2-factor argument form kvcalloc() instead of kvzalloc(). Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
5325bc82 -
由 Arnd Bergmann 创作于
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because the ordinary load/store instructions (ldr, ldrh, ldrb) can tolerate any misalignment of the memory address. However, load/store double and load/store multiple instructions (ldrd, ldm) may still only be used on memory addresses that are 32-bit aligned, and so we have to use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we may end up with a severe performance hit due to alignment traps that require fixups by the kernel. Testing shows that this currently happens with clang-13 but not gcc-11. In theory, any compiler version can produce this bug or other problems, as we are dealing with undefined behavior in C99 even on architectures that support this in hardware, see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 . Fortunately, the get_unaligned() accessors do the right thing: when building for ARMv6 or later, the compiler will emit unaligned accesses using the ordinary load/store instructions (but avoid the ones that require 32-bit alignment). When building for older ARM, those accessors will emit the appropriate sequence of ldrb/mov/orr instructions. And on architectures that can truly tolerate any kind of misalignment, the get_unaligned() accessors resolve to the leXX_to_cpup accessors that operate on aligned addresses. Since the compiler will in fact emit ldrd or ldm instructions when building this code for ARM v6 or later, the solution is to use the unaligned accessors unconditionally on architectures where this is known to be fast. The _aligned version of the hash function is however still needed to get the best performance on architectures that cannot do any unaligned access in hardware. This new version avoids the undefined behavior and should produce the fastest hash on all architectures we support. Reported-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jason A. Donenfeld <Jason@zx2c4.com> Acked-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
ea6b8e7b -
由 Jason A. Donenfeld 创作于
The comment to sk_change_net is instructive: Kernel sockets, f.e. rtnl or icmp_socket, are a part of a namespace. They should not hold a reference to a namespace in order to allow to stop it. Sockets after sk_change_net should be released using sk_release_kernel We weren't following these rules before, and were instead using __sock_create, which means we kept a reference to the namespace, which in turn meant that interfaces were not cleaned up on namespace exit. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
8e40dd62 -
由 Mathias Krause 创作于
The register constraints for the inline assembly in fsqr() and fsqr2() are pretty tight on what the compiler may assign to the remaining three register variables. The clobber list only allows the following to be used: RDI, RSI, RBP and R12. With RAP reserving R12 and a kernel having CONFIG_FRAME_POINTER=y, claiming RBP, there are only two registers left so the compiler rightfully complains about impossible constraints. Provide alternatives that'll allow a memory reference for 'out' to solve the allocation constraint dilemma for this configuration. Also make 'out' an input-only operand as it is only used as such. This not only allows gcc to optimize its usage further, but also works around older gcc versions, apparently failing to handle multiple alternatives correctly, as in failing to initialize the 'out' operand with its input value. Signed-off-by:
Mathias Krause <minipli@grsecurity.net> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
3c9f3b69 -
由 Jason A. Donenfeld 创作于
Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
743eef23 -
由 Jason A. Donenfeld 创作于
It's been over a year since we announced sunsetting this. Link: https://lore.kernel.org/wireguard/CAHmME9rckipsdZYW+LA=x6wCMybdFFA+VqoogFXnR=kHYiCteg@mail.gmail.com/T Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
4f4c0198 -
由 Jason A. Donenfeld 创作于
Rather than passing all variables as modified, pass ones that are only read into that parameter. This helps with old gcc versions when alternatives are additionally used, and lets gcc's codegen be a little bit more efficient. This also syncs up with the latest Vale/EverCrypt output. This also forward ports 3c9f3b69 ("crypto: curve25519-x86_64: solve register constraints with reserved registers"). Cc: Aymeric Fromherz <aymeric.fromherz@inria.fr> Cc: Mathias Krause <minipli@grsecurity.net> Link: https://lore.kernel.org/wireguard/1554725710.1290070.1639240504281.JavaMail.zimbra@inria.fr/ Link: https://github.com/project-everest/hacl-star/pull/501 Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
273018b7 -
由 Jason A. Donenfeld 创作于
We make too nuanced use of ptr_ring to entirely move to the skb_array wrappers, but we at least should avoid the naughty function pointer cast when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch uses the __skb_array_destroy_skb wrapper for the cleanup, rather than directly providing kfree_skb, which is what other drivers in the same situation do too. Reported-by:
PaX Team <pageexec@freemail.hu> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
4eff63d2 -
由 Jason A. Donenfeld 创作于
We don't actualy need to write anything in the pool. Instead, we just force the total over 128, and we should be good to go for all old kernels. We also only need this on getrandom() kernels, which simplifies things too. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
ffb8cd62 -
由 Wang Hai 创作于
I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
fa32671b -
由 Jason A. Donenfeld 创作于
The previous commit fixed a memory leak on the send path in the event that IPv6 is disabled at compile time, but how did a packet even arrive there to begin with? It turns out we have previously allowed IPv6 endpoints even when IPv6 support is disabled at compile time. This is awkward and inconsistent. Instead, let's just ignore all things IPv6, the same way we do other malformed endpoints, in the case where IPv6 is disabled. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
ec89ca64 -
由 Jason A. Donenfeld 创作于
It turns out that by having CONFIG_ACPI=n, we've been failing to boot additional CPUs, and so these systems were functionally UP. The code bloat is unfortunate for build times, but I don't see an alternative. So this commit sets CONFIG_ACPI=y for x86_64 and i686 configs. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
f909532a -
由 Nikolay Aleksandrov 创作于
When we try to transmit an skb with md_dst attached through wireguard we hit a null pointer dereference in wg_xmit() due to the use of dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to dereference dst->dev. Since wireguard doesn't use md_dsts we should use skb_valid_dst(), which checks for DST_METADATA flag, and if it's set, then falls back to wireguard's device mtu. That gives us the best chance of transmitting the packet; otherwise if the blackhole netdev is used we'd get ETH_MIN_MTU. [ 263.693506] BUG: kernel NULL pointer dereference, address: 00000000000000e0 [ 263.693908] #PF: supervisor read access in kernel mode [ 263.694174] #PF: error_code(0x0000) - not-present page [ 263.694424] PGD 0 P4D 0 [ 263.694653] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 263.694876] CPU: 5 PID: 951 Comm: mausezahn Kdump: loaded Not tainted 5.18.0-rc1+ #522 [ 263.695190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [ 263.695529] RIP: 0010:dst_blackhole_mtu+0x17/0x20 [ 263.695770] Code: 00 00 00 0f 1f 44 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 10 48 83 e0 fc 8b 40 04 85 c0 75 09 48 8b 07 <8b> 80 e0 00 00 00 c3 66 90 0f 1f 44 00 00 48 89 d7 be 01 00 00 00 [ 263.696339] RSP: 0018:ffffa4a4422fbb28 EFLAGS: 00010246 [ 263.696600] RAX: 0000000000000000 RBX: ffff8ac9c3553000 RCX: 0000000000000000 [ 263.696891] RDX: 0000000000000401 RSI: 00000000fffffe01 RDI: ffffc4a43fb48900 [ 263.697178] RBP: ffffa4a4422fbb90 R08: ffffffff9622635e R09: 0000000000000002 [ 263.697469] R10: ffffffff9b69a6c0 R11: ffffa4a4422fbd0c R12: ffff8ac9d18b1a00 [ 263.697766] R13: ffff8ac9d0ce1840 R14: ffff8ac9d18b1a00 R15: ffff8ac9c3553000 [ 263.698054] FS: 00007f3704c337c0(0000) GS:ffff8acaebf40000(0000) knlGS:0000000000000000 [ 263.698470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 263.698826] CR2: 00000000000000e0 CR3: 0000000117a5c000 CR4: 00000000000006e0 [ 263.699214] Call Trace: [ 263.699505] <TASK> [ 263.699759] wg_xmit+0x411/0x450 [ 263.700059] ? bpf_skb_set_tunnel_key+0x46/0x2d0 [ 263.700382] ? dev_queue_xmit_nit+0x31/0x2b0 [ 263.700719] dev_hard_start_xmit+0xd9/0x220 [ 263.701047] __dev_queue_xmit+0x8b9/0xd30 [ 263.701344] __bpf_redirect+0x1a4/0x380 [ 263.701664] __dev_queue_xmit+0x83b/0xd30 [ 263.701961] ? packet_parse_headers+0xb4/0xf0 [ 263.702275] packet_sendmsg+0x9a8/0x16a0 [ 263.702596] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 263.702933] sock_sendmsg+0x5e/0x60 [ 263.703239] __sys_sendto+0xf0/0x160 [ 263.703549] __x64_sys_sendto+0x20/0x30 [ 263.703853] do_syscall_64+0x3b/0x90 [ 263.704162] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 263.704494] RIP: 0033:0x7f3704d50506 [ 263.704789] Code: 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 [ 263.705652] RSP: 002b:00007ffe954b0b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 263.706141] RAX: ffffffffffffffda RBX: 0000558bb259b490 RCX: 00007f3704d50506 [ 263.706544] RDX: 000000000000004a RSI: 0000558bb259b7b2 RDI: 0000000000000003 [ 263.706952] RBP: 0000000000000000 R08: 00007ffe954b0b90 R09: 0000000000000014 [ 263.707339] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe954b0b90 [ 263.707735] R13: 000000000000004a R14: 0000558bb259b7b2 R15: 0000000000000001 [ 263.708132] </TASK> [ 263.708398] Modules linked in: bridge netconsole bonding [last unloaded: bridge] [ 263.708942] CR2: 00000000000000e0 Link: https://github.com/cilium/cilium/issues/19428 Reported-by:
Martynas Pumputis <m@lambda.lt> Signed-off-by:
Nikolay Aleksandrov <razor@blackwall.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> [Jason: polyfilled for < 4.3] Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
f9d9b4db -
由 Jason A. Donenfeld 创作于
I hate to do this, but I still do not have a good solution to actually fix this bug across architectures. So just disable it for now, so that the CI can still deliver actionable results. This commit adds a large red warning, so that at least the failure isn't lost forever, and hopefully this can be revisited down the line. Link: https://lore.kernel.org/netdev/CAHmME9pv1x6C4TNdL6648HydD8r+txpV4hTUXOBVkrapBXH4QQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/YmszSXueTxYOC41G@zx2c4.com/ Link: https://lore.kernel.org/wireguard/CAHmME9rNnBiNvBstb7MPwK-7AmAN0sOfnhdR=eeLrowWcKxaaQ@mail.gmail.com/ Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
f8886735 -
由 Jason A. Donenfeld 创作于
The parallel tests were added to catch queueing issues from multiple cores. But what happens in reality when testing tons of processes is that these separate threads wind up fighting with the scheduler, and we wind up with contention in places we don't care about that decrease the chances of hitting a bug. So just do a test with the number of CPU cores, rather than trying to scale up arbitrarily. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
894152a5 -
由 Jason A. Donenfeld 创作于
Rather than having to hack up QEMU, just use the virtio serial device. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
33c87a11 -
由 Jason A. Donenfeld 创作于
Rather than setting this once init is running, set panic_on_warn from the kernel command line, so that it catches splats from WireGuard initialization code and the various crypto selftests. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
c7560fd0 -
由 Jason A. Donenfeld 创作于
They keep breaking their kernel and being difficult when I send patches to fix it, so just give up on trying to support this in the CI. It'll bitrot and people will complain and we'll see what happens at that point. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
ba45dd6f -
由 Jason A. Donenfeld 创作于
Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
3ec3e822 -
由 Jason A. Donenfeld 创作于
Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
18fbcd68 -
由 Jason A. Donenfeld 创作于
Also bump the c8s version stamp. Reported-by:
Vladimír Beneš <vbenes@redhat.com> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
99935b07 -
由 Jason A. Donenfeld 创作于
Nobody uses this and it's impossible to maintain given the current CI situation. RHEL 7 and 8 release remain for now, though that might not always be the case. See the link for details. Link: https://lists.zx2c4.com/pipermail/wireguard/2022-June/007664.html Suggested-by:
Philip J. Perry <phil@elrepo.org> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
3d3c92b4
显示
- src/compat/Kbuild.include 8 个添加, 0 个删除src/compat/Kbuild.include
- src/compat/compat-asm.h 0 个添加, 3 个删除src/compat/compat-asm.h
- src/compat/compat.h 33 个添加, 14 个删除src/compat/compat.h
- src/compat/dstmetadata/include/net/dst_metadata.h 3 个添加, 0 个删除src/compat/dstmetadata/include/net/dst_metadata.h
- src/compat/siphash/include/linux/siphash.h 4 个添加, 10 个删除src/compat/siphash/include/linux/siphash.h
- src/compat/siphash/siphash.c 24 个添加, 24 个删除src/compat/siphash/siphash.c
- src/compat/skb_array/include/linux/skb_array.h 11 个添加, 0 个删除src/compat/skb_array/include/linux/skb_array.h
- src/compat/udp_tunnel/udp_tunnel.c 7 个添加, 5 个删除src/compat/udp_tunnel/udp_tunnel.c
- src/crypto/zinc/curve25519/curve25519-x86_64.c 504 个添加, 293 个删除src/crypto/zinc/curve25519/curve25519-x86_64.c
- src/device.c 2 个添加, 1 个删除src/device.c
- src/dkms.conf 1 个添加, 1 个删除src/dkms.conf
- src/queueing.c 2 个添加, 1 个删除src/queueing.c
- src/ratelimiter.c 2 个添加, 2 个删除src/ratelimiter.c
- src/receive.c 13 个添加, 3 个删除src/receive.c
- src/socket.c 3 个添加, 2 个删除src/socket.c
- src/tests/netns.sh 23 个添加, 11 个删除src/tests/netns.sh
- src/tests/qemu/Makefile 10 个添加, 9 个删除src/tests/qemu/Makefile
- src/tests/qemu/arch/aarch64.config 4 个添加, 1 个删除src/tests/qemu/arch/aarch64.config
- src/tests/qemu/arch/aarch64_be.config 4 个添加, 1 个删除src/tests/qemu/arch/aarch64_be.config
- src/tests/qemu/arch/arm.config 4 个添加, 1 个删除src/tests/qemu/arch/arm.config