Whither WireGuard?
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) |