Changes v8->v9, along with who suggested it. -------------------------------------------- - [EVERYBODY] Zinc no longer ships generated assembly code. Rather, we now bundle in the original perlasm generator for it. This is ongoing joint work with Andy Polyakov upstream, so that the same .pl files can live in our tree as well as in the CRYPTOGAMS tree. I personally find that the code required to share this in both repositories to be a tiny bit ugly. I think there would be some degree of an advantage to removing that and making the .pl kernel-only, and then carefully tracking Andy's changes (as we already do). Previous opinions on the list, though, were that there's also significant advantage to being able to share the exact same code in both. And I think there's a decent amount of wisdom in that too. Since that appeared to be the prevailing view, and since it also has good reasons arguments, we'll go with that for now. Meanwhile, Andy is recently back from some time away, and so we'll be improving these even further in the months to come. Already there are a few things ready that haven't been integrated here just yet. - [Eric Biggers] In Zinc introductory commit, add more details on what Zinc is for and what the inclusion criteria are, as well as some notes on API. - Clarify the peer removal logic and make lifetimes more precise. - [Jann Horn] Use READ_ONCE for is_valid and is_dead. - [Jann Horn] No need to use atomic when the recounter is mutex protected. - [Andrew Lunn] Fix up macros and annotations in allowedips. - [Andrew Lunn] Increment drop counter when staged packets are dropped. - Use static constants instead of enums for 64-bit values in selftest. - Mark large constants as ULL in poly1305-donna64. - Fix sparse warnings in allowedips debugging code. - Do not use wg_peer_get_maybe_zero in timer callbacks, since we now can carefully control the lifetime of these functions and ensure they never execute after dropping the last reference. - Cleanup hashing in ratelimiter. - Do not guard timer removals, since del_timer is always okay. - [Theodore Ts'o, Andrew Lunn, Sultan Alsawaf] We now check for PM_AUTOSLEEP, which makes the clear-on-suspend decision a bit more general. - Set csum_level to ~0, since the poly1305 authenticator certainly means that no data was modified in transit. - [Andrejs Hanins] Use CHECKSUM_PARTIAL check for skb_checksum_help instead of skb_checksum_setup check. - [Ard Biesheuvel] Enable the selftests by default, and leave it to small-system builders to disable this. - [Sultan Alsawaf] We no longer allocate large hashtables as part of the net_device structure. - Iteration of allowed IPs per peer now uses a normal boring fast linked list instead of needing to traverse a giant tree. This makes retrieving peer properties over netlink several orders of magnitude faster. - The removal of all peers now includes two iterations through the peer list with a single synchronize_rcu_bh() in between iterations, as opposed to having one iteration, but a synchronize_rcu_bh() for every single peer. - [Arnd Bergmann] 64-bit timestamps. - The test suite now checks the validity of timestamps and checks that private keys are being properly clamped. - Numerous API changes made in-tree since v8, such as shedding _bh() on a few functions and networking API changes and such. - Following the Adiantum merge, the two commits that port the old crypto API over to use Zinc have been removed from this series. We can certainly add them back in at some point, but I thought it'd be favorable to at least begin to receive some sign-offs on the Zinc-specific commits, now that (hopefully all of) the previous feedback has been taken care of. The two commits porting it over are fairly standalone as well, so that shouldn't impact the ability to review this. For now those are living in the jd/with-cryptoapi-port branch of kernel.org's zx2c4/linux.git tree. This also allows us to move this all forward a little bit. ----------------------------------------------------------- This patchset is available on git.kernel.org in this branch, where it may be pulled directly for inclusion into net-next: * https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/log/?h=jd/wireguard ----------------------------------------------------------- WireGuard is a secure network tunnel written especially for Linux, which has faced around three years of serious development, deployment, and scrutiny. It delivers excellent performance and is extremely easy to use and configure. It has been designed with the primary goal of being both easy to audit by virtue of being small and highly secure from a cryptography and systems security perspective. WireGuard is used by some massive companies pushing enormous amounts of traffic, and likely already today you've consumed bytes that at some point transited through a WireGuard tunnel. Even as an out-of-tree module, WireGuard has been integrated into various userspace tools, Linux distributions, mobile phones, and data centers. There are ports in several languages to several operating systems, and even commercial hardware and services sold integrating WireGuard. It is time, therefore, for WireGuard to be properly integrated into Linux. Ample information, including documentation, installation instructions, and project details, is available at: * https://www.wireguard.com/ * https://www.wireguard.com/papers/wireguard.pdf As it is currently an out-of-tree module, it lives in its own git repo and has its own mailing list, and every commit for the module is tested against every stable kernel since 3.10 on a variety of architectures using an extensive test suite: * https://git.zx2c4.com/WireGuard https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/ * https://lists.zx2c4.com/mailman/listinfo/wireguard * https://www.wireguard.com/build-status/ The project has been broadly discussed at conferences, and was presented to the Netdev developers in Seoul last November, where a paper was released detailing some interesting aspects of the project. Dave asked me after the talk if I would consider sending in a v1 "sooner rather than later", hence this patchset. Zinc was presented at Kernel Recipes in September, and a video is available online. Both Zinc and WireGuard were presented at Plumbers in Vancouver in November. * https://www.wireguard.com/presentations/ * https://www.wireguard.com/papers/wireguard-netdev22.pdf * Zinc talk: https://www.youtube.com/watch?v=bFhdln8aJ_U * Netdev talk: https://www.youtube.com/watch?v=54orFwtQ1XY The cryptography in the protocol itself has been formally verified by several independent academic teams with positive results, and I know of two additional efforts on their way to further corroborate those findings. The version 1 protocol is "complete", and so the purpose of this review is to assess the implementation of the protocol. However, it still may be of interest to know that the thing you're reviewing uses a protocol with various nice security properties: * https://www.wireguard.com/formal-verification/ This patchset is divided into four segments. The first introduces a very simple helper for working with the FPU state for the purposes of amortizing SIMD operations. The second segment is a small collection of cryptographic primitives, split up into several commits by primitive and by hardware. The third shows a non-WireGuard use case for Zinc. The last is WireGuard itself, presented as an unintrusive and self-contained virtual network driver. It is intended that this entire patch series enter the kernel through DaveM's net-next tree. Subsequently, WireGuard patches will go through DaveM's net-next tree, while Zinc patches will go through Greg KH's tree in cases when an entire development cycle has no relationships with existing code in crypto/; however, if there are any relationships with code in crypto/, then pull requests will be sent to Herbert instead in case there are merge conflicts. Enjoy, Jason Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> Cc: Eric Biggers <ebiggers@xxxxxxxxxx> Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Samuel Neves <samuel.c.p.neves@xxxxxxxxx> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cc: linux-crypto@xxxxxxxxxxxxxxx Cc: linux-kernel@xxxxxxxxxxxxxxx Cc: netdev@xxxxxxxxxxxxxxx
