Message-Id: <20190322071122.6677-1-Jason@zx2c4.com>
Date:   Fri, 22 Mar 2019 01:11:03 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Eric Biggers <ebiggers@...nel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Samuel Neves <samuel.c.p.neves@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: [PATCH net-next v9 00/19] WireGuard: Secure Network Tunnel

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@...ux-foundation.org>
Cc: "David S. Miller" <davem@...emloft.net>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Eric Biggers <ebiggers@...nel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Samuel Neves <samuel.c.p.neves@...il.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Cc: netdev@...r.kernel.org

Powered by blists - more mailing lists