
WireGuarding the mainline - thinxer
https://lwn.net/SubscriberLink/761939/4cee93b4fe564556/
======
mirimir
Quoting Linus Torvalds:[0]

> I see that Jason actually made the pull request to have wireguard included
> in the kernel.

> Can I just once again state my love for it and hope it gets merged soon?
> Maybe the code isn't perfect, but I've skimmed it, and compared to the
> horrors that are OpenVPN and IPSec, it's a work of art.

0) [https://lwn.net/ml/linux-
kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04...](https://lwn.net/ml/linux-
kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04Qv9eg0KQhwKfyJY0vFvoD3g@mail.gmail.com/)

Edit: fixed URL

~~~
pfranz
That's great to hear, but I wonder if anyone has insight on the rest of the
article. Is this Zinc API a prerequisite for WireGuard to be included? Is the
fact that Zinc won't support hardware encryption a no-go or is the expectation
they give reasonable? Has the kernel had any large API refactoring similar the
crypto/Zinc (I would assume it has)--how did they play out?

~~~
caf
There seems to be broad agreement for the need for a set of software crypto
implementations with a straightforward synchronous, static dispatching API.
The discussions seem to be mainly around code organisation and plumbing that
API as an underlying implementation used by the dynamic dispatch asynchronous
crypto API.

~~~
zx2c4
Right. So basically v2 of the Zinc patchset will address the nice points
brought up on the list, and I think things should proceed nicely.

~~~
rurban
Jason: Any word on the name yet? My concern is the confusion with the existing
my minizinc and flatzinc project, a standard constraint modeling language,
which has nothing to do with crypto. There should be some better name for the
Linux crypto lib.

~~~
majewsky
So what? Name clashes happen all the time. Before seeing this comment, I had
never heard of minizinc and flatzinc. In fact, if you had asked me if Zinc
clashes with anything, I'd have thought of Tinc (which is a VPN product, so
roughly in the same space).

------
efiecho
I'm really looking forward to start experimenting with Wireguard. Jason A.
Donenfeld is also the creator of my favorite password manager
[https://www.passwordstore.org/](https://www.passwordstore.org/) and recently
I found a neat web frontend for git called cgit, lo and behold, when I looked
it up I saw that Jason was the creator. He makes some really cool high quality
stuff.

~~~
Boulth
> He makes some really cool high quality stuff.

Couldn't agree more, all of his software is really nicely designed and
implementated. Moreover I had a chance of exchanging emails with him and he's
a really nice person.

~~~
tptacek
He really is. We just got done hanging out with him at Black Hat, and he's one
of the nicer people I've met here. A+++ would hang out again.

------
pimeys
A couple of days ago I started testing with WireGuard and installed it to my
Omnia Turris router. Mullvad provides WireGuard servers[0] for testing with a
reasonable price, and I've been routing all the traffic from our apartment
through WireGuard without any problems. The speed is just amazing after seeing
the disappointing performance of OpenVPN, I can easily push 300-400 MB/s
through the router, finally removing the last reason to not use a VPN for all
the traffic.

[0]
[https://mullvad.net/en/guides/category/wireguard/](https://mullvad.net/en/guides/category/wireguard/)

~~~
vardump
> I can easily push 300-400 MB/s

Wow. (For Wireguard performance and the link speed.)

10 Gbps link or just on the local network?

~~~
namibj
I presume a typo....

~~~
vardump
AFAIK 10 Gbps is the highest consumer internet bandwidth in several countries.
So it's still possible.

------
andreareina
Does anyone know _why_ reverse christmas tree order of declarations (i.e.
longest to shortest line length) is part of the style guide?

~~~
catwell
I don't know in their case, but I know it's the style used by Hisham Muhammad
(author of htop and LuaRocks among other things), and he explained why here:
[https://hisham.hm/2018/06/16/when-listing-repeated-things-
ma...](https://hisham.hm/2018/06/16/when-listing-repeated-things-make-
pyramids/)

------
Animats
That this has to be in the kernel is a failure of the Linux architecture. This
is middleware.

~~~
catwell
The only reason for it to be in the kernel is performance. There are userspace
implementations already, like on Windows and macOS.

~~~
rwmj
Because everyone knows kernel code runs faster than userspace code, right? Er
no, because of architectural problems.

~~~
catwell
If you're going to argue this then I agree with tptacek, you must also think
it's an architectural problem that filesystems cannot all be implemented over
FUSE with performance equivalent to their kernel versions.

Yes, TUN is not 0-copy. Is there an equivalent that's as fast as the kernel in
any other major OS? (I'm asking that honestly, I have no idea.) If there is,
is in-kernel networking on that OS as fast as on Linux?

The Linux network stack is what it is, there have been recent improvements for
it (e.g. DPDK), but I think it must not be so bad given it powers most of the
Internet.

~~~
rwmj
It doesn't have to be "over FUSE". There are microkernels out there like QNX
and L4 which solve the filesystem in userspace problem, are extremely fast,
and have done this for decades. You likely have a realtime L4 instance in your
phone doing the real work talking to the phone network. Heck even my Nintendo
Switch has a simple microkernel OS, with an unspectacular ARM processor, and
it runs _games_ \- one of the most performance sensitive applications that
regular people use.

~~~
tptacek
Right, but L4 isn't even an operating system; it's an OS fabric, on which OS
personalities are built. Nobody doubts you can build a microkernel
architecture where filesystems and VPNs are equivalently performant in
userland and the kernel, but nobody has managed to do that for a mainstream
OS.

It's telling that xnu started out on Mach with a FreeBSD "personality", and
grew into another shaggy monolith.

The L4 in your baseband or your enclave is not running anything resembling a
general purpose operating system.

So I guess my argument is: sure, you could design and build VPNOS, the OS
where VPNs are fast and never need to touch the kernel. But nobody wants that
OS.

~~~
Fnoord
Minix. Rumor is it runs on a lot of Intel CPUs...

~~~
wolf550e
What is the performance of Minix running general desktop and server workloads?

------
nickpsecurity
"He pointed out that Zinc cannot support hardware cryptographic accelerators,
something that Donenfeld regards as a feature. "

Why is not supporting hardware acceleration a feature? Or is the objection to
something more specific having to do with currently-available accelerators?

~~~
evil-olive
The idea is that hardware acceleration is a niche feature, so it should be
kept out of the core, low-level crypto primitives, and then a higher-level API
can be built that allows dynamic dispatch to an accelerator if available:

[https://lkml.org/lkml/2018/8/3/15](https://lkml.org/lkml/2018/8/3/15)

> A very large majority of in-kernel crypto users (by number of call sites
> under a _very_ brief survey, not by number of CPU cycles) just want to do
> some synchronous crypto on a buffer that is addressed by a regular pointer.
> Most of these users would be slowed down if they used any form of async
> crypto, since the CPU can complete the whole operation faster than it could
> plausibly initiate and complete anything asynchronous. And, right now, they
> suffer the full overhead of allocating a context (often with alloca!),
> looking up (or caching) some crypto API data structures, dispatching the
> operation, and cleaning up.

> So I think the right way to do it is to have directly callable functions
> like zinc uses and to have the fancy crypto API layer on top of them. So if
> you actually want async accelerated crypto with scatterlists or whatever,
> you can call into the fancy API, and the fancy API can dispatch to hardware
> or it can dispatch to the normal static API.

~~~
floatboth
I guess they don't count CPU instruction based accelerators like AES-NI as
accelerators?

~~~
crest
They do not. The difference is the same as having a BLAS implementation that
uses the SIMD units to their potential and one that supports a dedicated
sparse matrix multiply ASIC connected via some high bandwidth bus. In the
first case the caller doesn't have to worry about the implementation details
it is just a performance optimization. In the other case you have to use an
API that has to be more cumbersome to deal with multiplexing the accelerator
and moving data.

------
ghayes
Off topic: Does anyone have a good tutorial on setting up Wiregaurd on a cloud
server to act as a VPN? I’m currently using Algo from Trail of Bits, which is
great, but takes a lot on control out of my hands through its Ansible scripts.

~~~
mirimir
Others have posted great links. But one great aspect is how _simple_ it is.
The hardest part is getting a kernel module that works with your kernel. In my
experience, the best way to do that is to build it. And that's the hardest
part in getting WireGuard working. In Debian, that means using the latest
stable release (at least) with the latest kernel.

Once you have WireGuard working, creating tunnels is utterly trivial. For a
toy implementation:

    
    
        peer 0 with IPv4 address 1.2.3.4
        
        # ip link add dev wg0 type wireguard
        # ip link list
          [see wg0]
        # wg genkey | tee privatekey | wg pubkey > publickey
        # mkdir wg
        # mv privatekey publickey ./wg/
        # ip address add dev wg0 10.0.10.1 peer 10.0.10.2
        # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
        # ip link set wg0 up
        # wg
          interface: wg0
            public key: 0GS...0U=
            private key: (hidden)
            listening port: 51820
        # wg set wg0 peer IlC...QI= allowed-ips 0.0.0.0/0 endpoint 6.7.8.9:51820
        
        peer 1 with IPv4 address 6.7.8.9
        
        # ip link add dev wg0 type wireguard
        # ip link list
          [see wg0]
        # wg genkey | tee privatekey | wg pubkey > publickey
        # mkdir wg
        # mv privatekey publickey ./wg/
        # ip address add dev wg0 10.0.10.2 peer 10.0.10.1
        # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
        # ip link set wg0 up
        # wg
          interface: wg0
            public key: IlC...QI=
            private key: (hidden)
            listening port: 51820
        # wg set wg0 peer 0GS...0U= allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:51820

~~~
rsync
"Others have posted great links. But one great aspect is how simple it is."

(generate new keys to manage, create new network interfaces, assign new IPs,
run wireguard ...)

I would agree that this is _relatively simple_ but only compared to the other
mainstream options (namely, OpenVPN and IPSEC) but it is much, much more
complicated than sshuttle[1] which distinguishes itself by allowing you to use
_any ssh server_ as a VPN endpoint.

No server side software install is required - all you need on the endpoint is
an ssh login.

[1] [https://github.com/sshuttle](https://github.com/sshuttle)

~~~
zx2c4
I think sshuttle is pretty cool. It does layer 3 tunneling over TCP in the
right way. Usually when VPNs (like OpenVPN) try to tunnel IP packets over TCP,
if those IP packets contain TCP data itself, then you have this problem with
tunneling TCP over TCP, and the rate and congestion control algorithms of the
two instances of TCP step all over each other, and performance becomes
miserable. But sshuttle has done something pretty neat to fix that: it
actually parses the TCP in the packets it receives, reconstructs those packets
into a normal byte stream, and then sends that over TCP, reflowed, to then be
converted back into the original TCP stream on the other end. It's a tiny bit
involved, but they made it work well, and most of the time sshuttle "just
works."

~~~
beagle3
Indeed. It even has (or at least had in previous versions) a configurable
ping-time monitor that traded some bandwidth for interactivity - which is
another part of what makes it work so well.

------
Kurtz79
What is the status of WireGuard in terms of client device support?

The main advantage of IPsec and OpenVPN is that they are either natively
supported by all major OSs (desktop and mobile) or there are apps freely
available for that purpose.

~~~
chupasaurus
Linux, Android and macOS (through brew app) are supported, Windows and iOS
clients are in development.

------
chrisper
Does anyone know a good Windows client?

I only know TunSafe, which now has finally been open sourced. But it was still
controversial software. So any alternative would be nice.

~~~
nostream
I've never really understood what was controversial with TunSafe more than it
was closed source so it was hard for others to review the code, but now it's
open source.

As a former fan of WireGuard, I would STRONGLY advise against using ANY
WireGuard implementation and that includes the official one.

As it is now, there seems to be only one person in the world who believes that
they have the knowledge to determine if a WireGuard implementation is secure
or not, and it is the founder himself.

So much for the 4000 lines of code that was supposed to be easily audited and
understandable by others.

Avoid WireGuard until there is an outside group that can review the protocol
and implementations of the protocol. For as it is now, the founder accuses all
third party implementations of being unsecure but without being able to state
why (more than it feels he has something personal against them).

It all feels too immature.

------
pingec
Wireguard looks awesome. Any news about a windows wireguard implementation?

~~~
kbaker
There's TunSafe, BUT with caveats:
[https://news.ycombinator.com/item?id=16515637](https://news.ycombinator.com/item?id=16515637)

~~~
ludde
TunSafe is Open Source nowadays so most of those caveats are moot.

~~~
zx2c4
I still believe TunSafe's interoperability and standing security issues are
significant, and that TunSafe's existence and confusion-potential are
generally damaging to the WireGuard project, as has been the adversarial
position of their developer. That project is going in a number of really
undesirable directions from a security perspective. I would encourage folks to
stay away from this software.

For those who are after Windows clients, the WireGuard project will hopefully
have one quite soon, and of course we're happy to work with interested Windows
developers who are working on similar projects with a security-minded
attitude.

\---

I'm sure the subsequent replies to this message will have plenty of outcry,
demands for details, misinformation, and accusations, to bait this into a long
sprawling thread. I'd like to preemptively step out of that kind of
mudslinging. But I do think it's important to warn users, hence the note
above.

~~~
mmozeiko
What are the current security issues with TunSafe?

~~~
nostream
So far, I have not heard anyone who has found any security holes and I'm
active in the #WireGuard IRC channel with 300+ users, where many have looked
at the code. There may be some unscrupulous hacker who has reviewed the code
and found something but choose not to publish it, but it may also apply to
WireGuard's source code.

A security hole in WireGuard's wg-quick that many use to establish the
connection is that it allows the .conf file to download and execute programs
without asking the user, and this feature is enabled by default.

This is basically a good feature and allows admins to run custom software as
soon as the connection has been established.

However, it allows an evil (or NSA-hooked) VPN provider to issue .conf files
to infect the user's computer with malicious code because users of VPN
services rarely review the .conf files.

TunSafe has the same feature but it is disabled by default and requires Admin
privileges to enable it.

I like that TunSafe seems to have more restrictive security settings as
default, though it may not be appreciated by hardcore users.

------
microcolonel
> _Andy Lutomirski was generally favorable as well, noting that he has tried
> to carry out some similar changes to the cryptographic code in the past.
> Support for hardware accelerators should, he said, be built on top of Zinc;
> code needing that support could then use the more complex API that would be
> required, and the Zinc implementations could be used as fallbacks when
> acceleration is not available or practical to use._

This seems like a flawless approach. The Zinc approach seems to be preferred
(by those involved) for simple software-only use cases, and the more complex
use cases seem to be composed of operations which Zinc could implement.

It's good that they're not just going to plop the thing in there in a degraded
state (with probably worse performance [and DoS resistance] than the current
out of tree/dkms distributions of wireguard).

~~~
zx2c4
> It's good that they're not just going to plop the thing in there in a
> degraded state (with probably worse performance [and DoS resistance] than
> the current out of tree/dkms distributions of wireguard).

Yea, indeed, I'm really trying to get the mainline version to have the same
performance and security characteristics as the out-of-tree module version.

(And after it's mainlined, the out-of-tree module will only exist as
compatibility for older kernels, and I'll have some scripts to automatically
extract a mainline kernel into a backport.)

