path: root/zero-zero-text.txt
diff options
Diffstat (limited to 'zero-zero-text.txt')
1 files changed, 93 insertions, 0 deletions
diff --git a/zero-zero-text.txt b/zero-zero-text.txt
new file mode 100644
index 000000000000..22a270ef4595
--- /dev/null
+++ b/zero-zero-text.txt
@@ -0,0 +1,93 @@
+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
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: "David S. Miller" <davem@davemloft.net>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Eric Biggers <ebiggers@kernel.org>
+Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Cc: Samuel Neves <samuel.c.p.neves@gmail.com>
+Cc: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: linux-crypto@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: netdev@vger.kernel.org