Whither WireGuard?

It has been just over one full year since the WireGuard virtual private network implementation was reviewed here. WireGuard has advanced in a number of ways since that article was written; it has gained many happy users, has been endorsed by Linus Torvalds, and is now supported by tools like NetworkManager. There is one notable thing that has not happened, though: WireGuard has not yet been merged into the mainline kernel. After a period of silence, WireGuard is back, and it would appear that the long process of getting upstream is nearly done.

A new version of the WireGuard patches was posted on March 22. WireGuard itself is not particularly controversial; few people have raised complaints about its design or implementation. The sticking point is the "Zinc" cryptographic library that WireGuard uses. Zinc was born out of frustration with the kernel's current cryptographic layer, which is seen by many as being far too difficult to use. Zinc is, in essence, an entirely new cryptographic layer that sits alongside the current code, duplicating a lot of functionality within the kernel but providing an easier interface for cryptographic tasks.

There are a few complaints that have been heard about Zinc. One of those revolves around the fact that Zinc isn't just a new API for accessing cryptographic algorithms; it also includes it own implementation of those algorithms, duplicating functionality that the kernel already has. WireGuard author Jason Donenfeld defends these new implementations, probably correctly, as having been subjected to a higher level of cryptographic review. Kernel developers strongly dislike this kind of duplication, though; they will argue that, if the new implementation of a specific algorithm is better, it should simply replace the existing one rather than duplicating it. That way, there is only one version to maintain, and all users will be able to take advantage of whatever benefits it offers.

The duplicated algorithms have been a sticking point for some time, but it would appear that a solution is in the works. Crypto maintainer Herbert Xu has posted a version of Zinc that introduces the new API, but which uses the existing algorithm implementations rather than Donenfeld's new ones. That makes the API available for users like WireGuard while removing the new algorithm implementations from the discussion for now. Those implementations can, in the future, be evaluated on their own merits and merged, one at a time, when a consensus emerges that they are better.

Past discussions might lead one to expect that Donenfeld would resist this move, but this time around he responded: "I think we're slightly closer to being same page". He plans to make some changes to Xu's version of Zinc, but the version he intends to post will still use existing, in-kernel algorithms where they are available. Assuming that everybody likes the result, one of the major long-term roadblocks to the merging of WireGuard will have been overcome.

Duplication of cryptographic functions is not the only complaint about Zinc, though; others were expressed by Ard Biesheuvel, whose criticisms have done a fair amount to impede Zinc in the past — but those criticisms have also resulted in numerous improvements to the code. Biesheuvel described Zinc as a "layering violation", and complained that it is unable to use the asynchronous algorithm implementations in the kernel. That is by design: Zinc explicitly only supports synchronous implementations (where the caller waits until each operation is done). Asynchronous implementations (which run in parallel, often on an external accelerator, while the caller does something else) are seen as too complex and providing too little benefit.

Biesheuvel disagrees with that view of asynchronous operations, and fears that, in the future, somebody will have to bolt asynchronous support onto Zinc. He would much rather see development effort going into fixing the deficiencies in the existing cryptographic API. He is not alone in this view, but others disagree, including Torvalds, who declared himself to be strongly in the Zinc camp:

He went on to say that "none of the async accelerator code has ever been worth anything on real hardware and on any sane and real loads"; see his message for the details on his reasoning. If asynchronous crypto accelerators lack value in the real world, then it makes some sense to introduce an API that effectively ignores them. Naturally, this view of asynchronous crypto devices is not universally shared, or support for them would not exist in the kernel. See, in particular, this message from Pascal Van Leeuwen for a rebuttal of some of Torvalds's criticisms. But it does seem clear that asynchronous crypto is not particularly useful to a wide variety of use cases.

If the view expressed by Torvalds (and implicitly by Xu) wins out, and if the next posting of Zinc adequately addresses the concerns regarding duplicated algorithms, then Zinc's path into the mainline will start to look relatively clear. Unless some new problems arise with WireGuard (which seems unlikely, since even those who are opposed to Zinc tend to be supportive of WireGuard), it should be set to be merged as soon as Zinc gets in. That should bring a happy ending to the longish story of getting WireGuard into the mainline, conceivably as soon as the 5.2 development cycle.

Index entries for this article
Kernel	Networking/Virtual private networks
Security	Encryption/Network
Security	Linux kernel/Virtual private network (VPN)

---

to post comments