[net-next,v7,00/28] WireGuard: Secure Network Tunnel

Changes v6->v7, along with who suggested it.
--------------------------------------------
  - Account for big-endian 2^26 conversion in Poly1305.
  - Account for big-endian NEON in Curve25519.
  - Fix macros in big-endian AArch64 code so that this will actually run
    there at all.
  - [Ard Biesheuvel] Prefer if (IS_ENABLED(...)) over ifdef mazes when
    possible.
  - [Ard Biesheuvel] Call simd_relax() within any preempt-disabling glue
    code every once in a while so as not to increase latency if folks
    pass in super long buffers.
  - [Andy Polyakov] Prefer compiler-defined architecture macros in
    assembly code, which puts us in closer alignment with upstream
    CRYPTOGAMS code, and is cleaner.
  - [Andrew Lunn] Non-static symbols are prefixed with wg_ to avoid
    polluting the global namespace.
  - [Ard Biesheuvel] Return a bool from simd_relax() indicating whether
    or not we were rescheduled.
  - [Ard Biesheuvel] Reflect the proper simd conditions on arm.
  - [Ard Biesheuvel] Do not reorder lines in Kbuild files for the simd
    asm-generic addition, since we don't want to cause merge conflicts.
  - [Ard Biesheuvel] WARN() if the selftests fail in Zinc, since if this
    is an initcall, it won't block module loading, so we want to be loud.
  - [Ard Biesheuvel] Document some interdependencies beside include
    statements.
  - [Ard Biesheuvel] Remove HAVE_*_ARCH_IMPLEMENTATION in intermediate
    commits.
  - Add missing static statement to fpu init functions.
  - Use union in chacha to access state words as a flat matrix, instead
    of casting a struct to a u8 and hoping all goes well. Then, by passing
    around that array as a struct for as long as possible, we can update
    counter[0] instead of state[12] in the generic blocks, which makes it
    clearer what's happening.
  - [Ard Biesheuvel] Remove __aligned(32) for chacha20_ctx since we no
    longer use vmovdqa on x86, and the other implementations do not require
    that kind of alignment either.
  - Submit patch to ARM tree for adjusting RiscPC's cflags to be -march=armv3
    so that we can build code that uses umull.
  - [Ard Biesheuvel] Allow CONFIG_ARM[64] to imply [!]CONFIG_64BIT, and use
    zinc arch config variables consistently throughout.
  - [Eric Biggers] Document rationale for the 2^26->2^64/32 conversion in
    code comments.
  - [Andrew Lunn] Convert all of remaining BUG_ON to WARN_ON.
  - [Eric Biggers] Include the Z3 proof of 2^26 conversion correctness in
    commit message for curosity of others (https://xn--4db.cc/ltPtHCKN/py).
  - [Ard Biesheuvel] Show importing of Andy Polyakov's code always in a
    separate commit for all architectures.
  - [Herbert Xu] Make more clear what "old" and "new" columns refer to in
    benchmarks.
  - [Ard Biesheuvel] Replace `bxeq lr` with `reteq lr` in ARM assembler to be
    compatible with old ISAs via the macro in <asm/assembler.h>.
  - [Eric Biggers] Account for multiple threads accessing the same tfm in the
    port of the current crypto API to Zinc.
  - [Ard Biesheuvel] Do not allow WireGuard to be a built-in if IPv6 is a
    module.
  - [Ard Biesheuvel] As neat as it is to have `default m`, nothing else in
    drivers/net has that, so we remove it, alas.
  - [Ard Biesheuvel] Writeback the base register and reorder multiplications
    in the NEON x25519 implementation.
  - Try all combinations of different implementations in selftests, so that
    potential bugs are more immediately unearthed.
  - The selftest infrastructure now generally prefers IS_ENABLED(..) over
    ifdefs, since the compiler is more than capable of trimming unused
    functions and static variables.
  - [Sultan Alsawaf] Self tests and SIMD glue code work with #include,
    which lets the compiler optimize these. Previously these files were .h,
    because they were included, but a simple grep of the kernel tree shows
    259 other files that carry out this same pattern. Only they prefer to
    instead name the files with a .c instead of a .h, so we now follow the
    convention.

-----------------------------------------------------------

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
will be presented at the conference 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 usage of Zinc within the existing crypto API and as a replacement
to the existing crypto API. 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

On Sat, Oct 06, 2018 at 04:56:44AM +0200, Jason A. Donenfeld wrote:
> Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto". It's also

> short, easy to type, and plays nicely with the recent trend of naming

> crypto libraries after elements. The guiding principle is "don't overdo

> it". It's less of a library and more of a directory tree for organizing

> well-curated direct implementations of cryptography primitives.

> 


As I've asked before: please Cc linux-crypto on the whole patch series,
including the cover letter.

- Eric