| Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you enjoy the content and want to see more, your subscription will help ensure LWN continues to thrive. Please visit this page to join us in keeping LWN alive on the web. |
It has been more than a year since the publication of this article on the WireGuard VPN implementation. WireGuard has improved in many ways since this article was published: it has many happy users, it was endorsed by Linus Torvalds , and it is now supported by tools like NetworkManager. One notable thing hasn't happened yet: WireGuard hasn't been merged into the mainline kernel yet. After a hiatus, WireGuard is back, and it looks like the long process of getting upstream is nearing completion.
A new version of the WireGuard patch was released on March 22nd . WireGuard itself isn't particularly controversial; there are few complaints about its design or implementation. The sticking point is the "Zinc" encryption library used by WireGuard . Zinc was born out of dissatisfaction with the kernel's current encryption layer, which many felt was too difficult to use. Essentially, Zinc is an entirely new cryptographic layer that exists alongside the current code, duplicating a lot of functionality in the kernel, but providing a simpler interface for cryptographic tasks.
People have some complaints about Zinc. One of these is that Zinc is not just a new API for accessing cryptographic algorithms, it also includes its own implementation of these algorithms, duplicating what the kernel already does. WireGuard author Jason Donenfeld has defended these new implementations as having undergone a higher level of cryptographic scrutiny, which is probably correct. Kernel developers, however, dislike this duplication very much; they will argue that if a new implementation of a particular algorithm is better, it should simply replace the existing algorithm rather than duplicate it. In this way, only one version needs to be maintained, and all users can enjoy the benefits it brings.
Repeating algorithms has been a thorny problem for some time, but now there seems to be a solution. Cryptocurrency maintainer Herbert Xu released a version of Zinc that introduces the new API, but uses an existing algorithm implementation instead of Donenfeld's new algorithm. This allows users like WireGuard to use the API, while the implementation of new algorithms is off the table for now. In the future, we can evaluate these algorithm implementations on their own merits and merge them one by one when there is a consensus that they are better.
Past discussions might have led to the idea that Donenfeld would resist the move, but this time he responded : "I think we're a little bit closer to the same
starting line". He plans to make some changes to Xu's version of Zinc, but the version he intends to release will still use the existing kernel algorithm. Assuming everyone likes the outcome, one of the main long-term hurdles to the WireGuard merger will be overcome.
The duplication of encryption functions is not the only complaint about Zinc, Ard Biesheuvel also expressed other complaints about Zinc. Biesheuvel described Zinc as a "layering violation
" and complained that it couldn't be implemented using asynchronous algorithms in the kernel. This is by design: Zinc only explicitly supports synchronous implementations (i.e. the caller waits for each operation to complete). Asynchronous implementations (often running in parallel on external accelerators while the caller does other things) were deemed too complex for too little benefit.
Biesheuvel disagrees with this view of asynchronous operations, and he worries that someone will add asynchronous support to Zinc in the future. He'd prefer to see developers working on fixing flaws in existing encryption APIs. He’s not alone in this view; others disagree, including Torvalds, who has declared himself a staunch supporter of the Zinc camp:
He went on to say: "Asynchronous accelerator code has no value on real hardware and on any normal real-world workload
. If asynchronous cryptographic accelerators lack value in the real world, it would make some sense to introduce an API that effectively ignores them." Of course, this view of asynchronous cryptographic devices is not universally accepted, otherwise support for them would not exist in the kernel. See in particular Pascal Van Leeuwen's some criticism of Torvalds Opinion 's rebuttal. But it's clear that asynchronous encryption isn't particularly useful for various use cases.
If the point expressed by Torvalds (and implied by Xu) prevails, and if Zinc's next article adequately addresses the issue of repeating algorithms, then Zinc's path to the mainline will start to become relatively clear. Unless there are new problems with WireGuard (which seems unlikely, since even anti-Zinc people tend to support WireGuard), it should be merged as soon as Zinc is added. This brings a happy ending to the long story of getting WireGuard into the mainline.
| This article index entry | |
|---|---|
| kernel | Network / Virtual Private Network |
| Safety | Encryption/Network |
| cyber security | Linux Kernel / Virtual Private Network (VPN) |
(log in to post a comment)