[LWN subscriber-only content] Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.
net! Free trial subscription
Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.
By Jonathan Corbet August 6, 2018 The WireGuard VPN tunnel has been under development — and attracting attention — for a few years now; LWN ran a review of it in March. While WireGuard can be found in a number of distribution repositories, it is not yet shipped with the mainline kernel because its author, Jason Donenfeld, hasn’t gotten around to proposing it for upstreaming. That changed on on July 31, when Donenfeld posted WireGuard for review . Getting WireGuard itself into the mainline would probably not be all that hard; merging some of the support code it depends on could be another story, though.
WireGuard implements a simple tunneling protocol allowing network traffic to be routed through a virtual private network provider. It has been developed with an eye toward smallness, ease of verification, and performance, rather than large numbers of features.
It is, according to the patch posting, ” used by some massive companies pushing enormous amounts of traffic “. Some effort has gone into making WireGuard widely available, an effort that has helped to create a significant user community. But the ultimate way to make this kind of software widely available is to get it into everybody’s kernel; that requires upstreaming.
Thus far, the WireGuard code itself does not appear to be hugely controversial. There are plenty of little issues to deal with, including the inevitable (for networking code) demand that variable declarations be put into “reverse Christmas tree” order, along with a few technical issues that would appear to be easily resolved. Dealing with those things will likely take a couple of iterations, but the real fate of WireGuard is likely to be driven by this “review” from Linus Torvalds: 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.
There is a potential sticking point, though. WireGuard, as one would expect, encrypts traffic between the ends of the tunnel, and endpoints perform cryptographic authentication of their peers. The kernel offers an extensive cryptographic subsystem that could be used to perform these operations, but Donenfeld turns out not to be a fan of that API. In an “upstreaming roadmap” posted last November, he stated his intent to ” embark on a multi-pronged effort to overhaul the crypto API “. In the end, he has created a completely new cryptographic subsystem for the kernel and based WireGuard on that rather than on the existing cryptographic code.
Even without seeing this work, one can imagine that an effort to thrash up a longstanding core API would be a relatively hard sell. Donenfeld seemed to be trying to make things harder yet: his “Zinc” cryptography API was posted as a single, 24,000-line patch that was duly rejected by the mailing-list filters.
It is available in his repository , though, for those who want to take a look. The changelog describes the motivations for Zinc in the sort of, shall we say, highly self-assured language favored by security-oriented developers.
It seems designed to raise enough hackles to prevent serious consideration of what is actually being proposed.
In short, Donenfeld argues, the kernel’s cryptographic API is far too complex and difficult to use. It is designed to work with acceleration hardware and allow sophisticated composition of operations, requiring users to do things like set up transform contexts and scatter/gather lists for the data to be encrypted. But most users simply want to perform a simple cryptographic operation and do not benefit from the complexity of the kernel’s API, so developers tend to avoid it. What’s needed, he says, is a different sort of cryptographic library: The kernel is in the business usually not of coming up with new uses of crypto, but rather implementing various constructions, which means it essentially needs a library of primitives, not a highly abstracted enterprise-ready pluggable system, with a few particular exceptions.
Zinc follows this philosophy by providing a simple set of cryptographic algorithms that can be called without any elaborate setup rituals.
A number of those algorithms duplicate functionality that already exists in the kernel’s cryptographic layer. There is talk in the changelog about eventually reworking the in-kernel code to be based on Zinc, but that work has not been done at this time.
While Zinc has not exactly been received with open arms, neither has it been rejected out of hand. Donenfeld does actually have a point when it comes to the complexity of the current cryptographic API.
The most detailed review so far has come from kernel cryptographic developer Eric Biggers who, after saying that he wanted to see WireGuard upstream, said that ” a few things are on the wrong track ” on the Zinc side. He would like to see the various algorithms split out and added separately, for example, making the patch set easier to review. He pointed out that Zinc cannot support hardware cryptographic accelerators, something that Donenfeld regards as a feature. All told, he seems to not be opposed to the overall concepts behind Zinc, but would like to see a number of changes in the implementation.
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. Lutomirski supported a number of Biggers’s requests for changes. Meanwhile, Herbert Xu, the maintainer of the cryptographic subsystem, has stayed out of the discussion.
Donenfeld has been generally receptive to the requests for changes, and has promised a new version of Zinc with many of the issues raised so far addressed. That will almost certainly not be the end of the discussion; that kind of deep surgery on a core kernel subsystem does not happen overnight. But if all of the participants in the conversation continue to be open to what the others are saying, the remaining kinks should be ironed out before too long, and WireGuard will finally have a path into the mainline. Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion. ( Log in to post comments) WireGuarding the mainline Posted Aug 7, 2018 1:54 UTC (Tue) by flussence (subscriber, #85566) [ Link ] I suppose this is as good a place to ask as any: what in an average Linux desktop distro actually makes use of the current crypto API? I see a few things required for filesystem checksums and wireless networking, but the latter is a weird case because hostapd/wpa_supplicant also wants userspace SSL libraries to speak WPA.
(Also I think this is the most positive reaction I’ve seen from Linus to anything. Maybe that comes from using other VPNs? 🙂 WireGuarding the mainline Posted Aug 7, 2018 5:35 UTC (Tue) by josh (subscriber, #17465) [ Link ] > what in an average Linux desktop distro actually makes use of the current crypto API?
Encrypted disks, filesystems that support file encryption, the CIFS/SMB filesystem, signed kernel modules, TCP Fast Open, Bluetooth, and various things that use compression (which goes through the crypto subsystem as well). WireGuarding the mainline Posted Aug 7, 2018 15:26 UTC (Tue) by luto (subscriber, #39314) [ Link ] I encountered some of this while doing VMAP_STACK.
The existing crypto APIs support for doing crypto on small stack buffers is mediocre, to put it mildly. WireGuarding the mainline Posted Aug 7, 2018 3:23 UTC (Tue) by unixbhaskar (subscriber, #44758) [ Link ] Whoa! that sounds great. Why people jumping for more feature??? It is designed to be used with one single thing and it should do what it suppose to do. More feature(most of them not used by anybody) , go and take a look at the other part. If it’s sticking with its current form with little bit enhancement in the future, which was suggested by other people, it will be good. WireGuarding the mainline Posted Aug 7, 2018 5:54 UTC (Tue) by zx2c4 (subscriber, #82519) [ Link ] Donenfeld seemed to be trying to make things harder yet: his “Zinc” cryptography API was posted as a single, 24,000-line patch that was duly rejected by the mailing-list filters. It is available in his repository, though, for those who want to take a look.
The changelog describes the motivations for Zinc in the sort of, shall we say, highly self-assured language favored by security-oriented developers.
It seems designed to raise enough hackles to prevent serious consideration of what is actually being proposed. Certainly not “trying to make things harder” and it wasn’t “designed to raise enough hackles”.
But rest assured the Zinc portion will be considerably different in form for v2. Split into several separably reviewable parts, each message will have very specific commentary on the particulars of each patch, so there will be less of the language that’s “favored by security-oriented developers,” opting instead to get right down to the point of the patch. And regardless, I’m happy iterating on this until it’s acceptable, as I think it’s a significant improvement on the status quo. WireGuarding the mainline Posted Aug 7, 2018 9:54 UTC (Tue) by kaliszad (subscriber, #125214) [ Link ] Thank You for Your hard work.
I have been in Your talk at 34C3. As I said after it, I would very much like to use WireGuard with some kind of failover like VRRP/ keepalived or Pacemaker.
I guess, this is a harder problem, than it looks. You have to move the virtual IP to the node (that is easily done) but the problem is to turn the interface on in such a way as to consider time outs and such of other dependent tasks. I haven’t looked into it, I had other stuff to do besides I will not be able to use unsupported (by Red Hat in my case) features on a cluster – the inclusion in the kernel would make it a likely addition to the enterprise distributions the next round.
Maybe, this business (like You say) is best left to some other management application, maybe a Pacemaker resource like systemd could start a unit or something. keepalived would probably need some kind of notify script that is executed on migration. I am just thinking out loud here. WireGuarding the mainline Posted Aug 7, 2018 12:19 UTC (Tue) by corbet (editor, #1) [ Link ] Apologies if the, let’s say, “language favored by LWN editors” raised some hackles of its own; obviously you weren’t out to upset people. The “significant improvement” part seems to be getting across – looking forward to having all of this in the mainline.
WireGuarding the mainline Posted Aug 7, 2018 13:20 UTC (Tue) by ms-tg (subscriber, #89231) [ Link ] > …the Zinc portion will be considerably different in form for v2. Split into several separably reviewable parts..
.
As others have said, *Thank You* for what you are doing!
Do you think, at the end of the Zinc v2 patch series, there will be the patches that refactor the existing crypto subsystem to use the new Zinc as the default non-accelerated implementation, removing all existing non-accelerated implementations outside of Zinc, and then keeping the existing crypto acceleration features as a layer on top of Zinc?
Super interested to see, as a “natural experiment”, if that level of refactoring and unification across subsystems can really occur in the current kernel development process in a situation like this?
Thanks, WireGuarding the mainline Posted Aug 7, 2018 6:17 UTC (Tue) by Cyberax ( ✭ supporter ✭ , #52523) [ Link ] To be fair, the bulk of Zinc code consists mostly of cut&pasted crypto implementations, including manually unrolled assembly code.
WireGuarding the mainline Posted Aug 7, 2018 15:16 UTC (Tue) by zx2c4 (subscriber, #82519) [ Link ] It’s a bit more than cut&paste — we worked on that assembly quite a bit. But indeed the vast majority of the patch is optimized assembly, which tends to be, well, long. WireGuarding the mainline Posted Aug 8, 2018 18:06 UTC (Wed) by lbt (subscriber, #29672) [ Link ] Does that assembly cover a variety of architectures? Is there fallback to C? WireGuarding the mainline Posted Aug 8, 2018 18:25 UTC (Wed) by zx2c4 (subscriber, #82519) [ Link ] Yes and yes. Kernel IPsec implementation Posted Aug 7, 2018 19:03 UTC (Tue) by rweikusat2 (subscriber, #117920) [ Link ] I did some work on the kernel IPsec code in the past (added a few features needed for a particular product) and compared to other parts of the kernel I’ve also worked on, eg, the AF_UNIX socket implementation or some of the USB code, I didn’t think it was that bad. Kernel IPsec implementation Posted Aug 8, 2018 14:14 UTC (Wed) by storner (subscriber, #119) [ Link ] From my understanding there is not so much criticism of the kernel IPSec implementation. It is the entire design of the IPSec specifications that is seen as “wrong”, in the sense that they are overly complex, difficult to understand and implement, and implementations are – for all practical purposes – impossible to review for security issues.
And since IPSec was designed many moons ago, it also carries a lot of cruft – but you cannot dump it because that would break interoperability between implementations.
Wireguard is a fresh start on designing a VPN. Sometimes the best solution really is to start from scratch. Kernel IPsec implementation Posted Aug 8, 2018 17:26 UTC (Wed) by rweikusat2 (subscriber, #117920) [ Link ] There’s a Linus Torvalds quote in the text: 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. I can’t comment on OpenVPN but I can comment on the Linux IPsec implementation and this comment would be “This is a reasonably organized and well-structured piece of code I could understand and change [to suit some specifc needs, eg, migrating IPv4-based IPsec SAs etc to different IPs/ ports if a client address changes] fairly easily”. The kernel does contain much worse things, examples I’m somewhat familiar with (due to other work) are UNIX domain sockets and the USB handling code.
I also don’t think the “the IPsec-specifications” are overly complex and difficult to understand but I admit that I’ve been working on a proprietary fork of an open source IKE implementation for years which might have helped here. But that’s a different conversation.
Kernel IPsec implementation Posted Aug 9, 2018 0:32 UTC (Thu) by luto (subscriber, #39314) [ Link ] I actually strongly dislike the Linux implementation. I have never looked at the code, but the fact that the encapsulated and plaintext packets are on the same interface makes using Wireshark or any other packet capture tool miserable. And getting firewall rules right is interesting at best. Kernel IPsec implementation Posted Aug 9, 2018 4:20 UTC (Thu) by zlynx (subscriber, #2285) [ Link ] It’s been a while for me, but I recall that IPsec packets have protocol 50 while UDP is 17 if you want to separate them. Kernel IPsec implementation Posted Aug 9, 2018 12:28 UTC (Thu) by rweikusat2 (subscriber, #117920) [ Link ] That’s usually not going to help because one will usually encounter ESP in UDP encapsulation so that NAT-T is possible. Kernel IPsec implementation Posted Aug 9, 2018 17:18 UTC (Thu) by zlynx (subscriber, #2285) [ Link ] When I used to run IPsec it was at the border gateways, so I never had to use UDP encapsulation. That would make it trickier I suppose.
Kernel IPsec implementation Posted Aug 9, 2018 12:47 UTC (Thu) by rweikusat2 (subscriber, #117920) [ Link ] Encapsulated datagrams either use IP protocol 50 or UDP and port 4500, filtering to exclude them or to look exclusivey at them is not more difficult than excluding ARP, SSH and STP and whatever other uninteresting/ noise traffic happens to appear on some interface. What’s more of an actual problem is that decapsulated reply traffic usually isn’t visible in tcpdump output (it’s entirely conceivable that I just don’t know how to make it visible).
But I was still making a statement about the code, so why did your “I want to talk about something entirely different” text get attached to that?
Linux IPsec also supports so-called “route-based VPNs”, BTW.
Kernel IPsec implementation Posted Aug 9, 2018 14:54 UTC (Thu) by rweikusat2 (subscriber, #117920) [ Link ] Minor error in here: “Decapsulated reply traffic” make no sense.
Assuming there’s a VPN server to which clients connect which utilizes some internal network ‘through’ a set of ESP tunnels and also acts as NAT gateway to the outside world for clients, the ESP/ ESP-in-UDP traffic, the incoming traffic on the internal network and the incoming and outgoing traffic from the external address of the gateway can be captured but not the reply traffic on the internal network (logically) originating from the internal address of the gateway and destined for the internal address of some client as that’s transformed according to the rules in the SPD before anything outside gets a chance to look at it (AIUI). WireGuarding the mainline Posted Aug 9, 2018 20:50 UTC (Thu) by lnnuser21821 (subscriber, #126296) [ Link ] Remind me why the kernel needs a crypto library instead of just having it in userspace again?
Copyright © 2018, Eklektix, Inc..
