cc5060ca - wireguard: do not use -O3

Fri, 04 Jun 2021 15:17:32 +0000

wireguard: do not use -O3Apparently, various versions of gcc have O3-related miscompiles. Lookingat the difference between -O2 and -O3 for gcc 11 doesn't indicatemiscompiles, but the difference also doesn't seem so significant forperformance that it's worth risking.Link: https://lore.kernel.org/lkml/CAHk-=wjuoGyxDhAF8SsrTkN0-YfCx7E6jUN3ikC_tn2AKWTTsA@mail.gmail.com/Link: https://lore.kernel.org/lkml/CAHmME9otB5Wwxp7H8bR_i2uH2esEMvoBMC8uEXBMH9p0q1s6Bw@mail.gmail.com/Reported-by: Linus Torvalds Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")Cc: stable@vger.kernel.orgSigned-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wireguard/Makefile

e7096c13 - net: WireGuard secure network tunnel

Sun, 08 Dec 2019 23:27:34 +0000

net: WireGuard secure network tunnelWireGuard is a layer 3 secure networking tunnel made specifically forthe kernel, that aims to be much simpler and easier to audit than IPsec.Extensive documentation and description of the protocol andconsiderations, along with formal proofs of the cryptography, areavailable at: * https://www.wireguard.com/ * https://www.wireguard.com/papers/wireguard.pdfThis commit implements WireGuard as a simple network device driver,accessible in the usual RTNL way used by virtual network drivers. Itmakes use of the udp_tunnel APIs, GRO, GSO, NAPI, and the usual set ofnetworking subsystem APIs. It has a somewhat novel multicore queueingsystem designed for maximum throughput and minimal latency of encryptionoperations, but it is implemented modestly using workqueues and NAPI.Configuration is done via generic Netlink, and following a review fromthe Netlink maintainer a year ago, several high profile userspace toolshave already implemented the API.This commit also comes with several different tests, both in-kerneltests and out-of-kernel tests based on network namespaces, taking profitof the fact that sockets used by WireGuard intentionally stay in thenamespace the WireGuard interface was originally created, exactly likethe semantics of userspace tun devices. See wireguard.com/netns/ forpictures and examples.The source code is fairly short, but rather than combining everythinginto a single file, WireGuard is developed as cleanly separable files,making auditing and comprehension easier. Things are laid out asfollows: * noise.[ch], cookie.[ch], messages.h: These implement the bulk of the cryptographic aspects of the protocol, and are mostly data-only in nature, taking in buffers of bytes and spitting out buffers of bytes. They also handle reference counting for their various shared pieces of data, like keys and key lists. * ratelimiter.[ch]: Used as an integral part of cookie.[ch] for ratelimiting certain types of cryptographic operations in accordance with particular WireGuard semantics. * allowedips.[ch], peerlookup.[ch]: The main lookup structures of WireGuard, the former being trie-like with particular semantics, an integral part of the design of the protocol, and the latter just being nice helper functions around the various hashtables we use. * device.[ch]: Implementation of functions for the netdevice and for rtnl, responsible for maintaining the life of a given interface and wiring it up to the rest of WireGuard. * peer.[ch]: Each interface has a list of peers, with helper functions available here for creation, destruction, and reference counting. * socket.[ch]: Implementation of functions related to udp_socket and the general set of kernel socket APIs, for sending and receiving ciphertext UDP packets, and taking care of WireGuard-specific sticky socket routing semantics for the automatic roaming. * netlink.[ch]: Userspace API entry point for configuring WireGuard peers and devices. The API has been implemented by several userspace tools and network management utility, and the WireGuard project distributes the basic wg(8) tool. * queueing.[ch]: Shared function on the rx and tx path for handling the various queues used in the multicore algorithms. * send.c: Handles encrypting outgoing packets in parallel on multiple cores, before sending them in order on a single core, via workqueues and ring buffers. Also handles sending handshake and cookie messages as part of the protocol, in parallel. * receive.c: Handles decrypting incoming packets in parallel on multiple cores, before passing them off in order to be ingested via the rest of the networking subsystem with GRO via the typical NAPI poll function. Also handles receiving handshake and cookie messages as part of the protocol, in parallel. * timers.[ch]: Uses the timer wheel to implement protocol particular event timeouts, and gives a set of very simple event-driven entry point functions for callers. * main.c, version.h: Initialization and deinitialization of the module. * selftest/*.h: Runtime unit tests for some of the most security sensitive functions. * tools/testing/selftests/wireguard/netns.sh: Aforementioned testing script using network namespaces.This commit aims to be as self-contained as possible, implementingWireGuard as a standalone module not needing much special handling orcoordination from the network subsystem. I expect for futureoptimizations to the network stack to positively improve WireGuard, andvice-versa, but for the time being, this exists as intentionallystandalone.We introduce a menu option for CONFIG_WIREGUARD, as well as providing averbose debug log and self-tests via CONFIG_WIREGUARD_DEBUG.Signed-off-by: Jason A. Donenfeld Cc: David Miller Cc: Greg KH Cc: Linus Torvalds Cc: Herbert Xu Cc: linux-crypto@vger.kernel.orgCc: linux-kernel@vger.kernel.orgCc: netdev@vger.kernel.orgSigned-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wireguard/Makefile

Changes in Makefile

cc5060ca - wireguard: do not use -O3

e7096c13 - net: WireGuard secure network tunnel