Progress on Zinc (thus WireGuard)

When last we looked at the WireGuard VPN code and its progress toward mainline inclusion, said progress was impeded by disagreements about the new "Zinc" cryptographic library that is added by the WireGuard patches. Since that August look, several more versions of WireGuard and Zinc have been posted; it would seem that Zinc is getting closer to being accepted. Once that happens, the networking developers are poised to review that portion of the code, which likely will lead to WireGuard in the kernel some time in the next development cycle or two.

Jason Donenfeld posted Zinc v3 as part of an updated WireGuard posting on September 10. Of the versions he has posted since our article (up to v6 as of this writing), v3 has gotten most of the comments. One of the main complaints about Zinc is that it creates a new crypto API in the kernel without really addressing why the existing one would not work for WireGuard. As Ard Biesheuvel put it:

But Greg Kroah-Hartman said that the current crypto API is too hard to use for many parts of the kernel, which leads to simpler, private implementations of crypto primitives sprinkled all over the kernel tree. He suggested that the existing crypto API be switched over time to use the Zinc primitives where that is possible. But Eric Biggers was concerned that no conversions of that sort have been done, which means there could be undiscovered problems in the Zinc API that will make it difficult to do so: "I don't think it makes sense to merge all this stuff without doing the conversions, or at the very least demonstrating how they will be done".

Donenfeld said that he is willing to do those conversions, but wants to get the series merged first. "I'd really prefer to land this series through net-next, and then after we can turn our attention to integrating this into the existing crypto API". But, as Andrew Lunn pointed out, that may be putting the cart ahead of the horse. He noted that the networking developers have not had a serious look at the WireGuard patches and won't "until the controversial part of the code, Zinc, has been sorted out". He also predicted that networking maintainer David Miller would not take the code into his tree without an Acked-by from the crypto maintainers.

Miller confirmed that assessment and clarified that even though he is listed as one of the two crypto maintainers, he would be looking for an ack from the other maintainer, Herbert Xu, as "I haven't done a serious review of crypto code in ages". Xu has been quiet, so far, on the Zinc patches, with one exception.

Donenfeld feels that Biesheuvel is not pleased with the existence of Zinc. When Biesheuvel listed the additional items that he thinks need to be addressed in Zinc, Donenfeld's response is prefaced by a number of worries about Biesheuvel: that he is "generally hostile to this whole initiative", is trying to "stall it indefinitely", and perhaps will just keep bikeshedding "until Zinc copies lots of the same design decisions from the present crypto API". Donenfeld did also say that he hoped these were all just fears and did not truly reflect what was happening. But that was when Xu stepped in to make it clear that he values the review that Biesheuvel has been doing:

For his part, Biesheuvel tried to make his intentions clear to Donenfeld in another part of the thread:

But the main technical objections that Biggers and Biesheuvel have raised were still being hashed out in the thread. Andy Lutomirski suggested that Donenfeld add a conversion of one of the algorithms in the existing crypto API to use Zinc as part of the patch set. After a bit of resistance, Donenfeld agreed. Conversions of the Poly1305 hash and ChaCha20 cipher (which are what WireGuard uses) in the existing crypto subsystem were part of the WireGuard v4 patch set.

Along the way, there have also been discussions about the OpenSSL implementations of some of the primitives (i.e. CRYPTOGAMS) that were incorporated into Zinc. These are written in assembly, but are actually generated from Perl scripts. Donenfeld has modified the assembly output in order to make it comply with kernel coding standards but has also made some other adjustments. That makes it difficult to keep the implementation in sync with any changes that OpenSSL might make, Biesheuvel noted. "Dumping 10,000s of lines of generated assembler in the kernel tree like that is really unacceptable IMO." Donenfeld said that he disagrees with the characterization of the code, but that getting his changes into the OpenSSL upstream is desirable.

Beyond that, there were some minor licensing concerns (and the resulting SPDX identifiers) with some files, which have seemingly been resolved. Similarly, some performance problems were noted and addressed. In short, Zinc is starting to look like something that could be merged. Donenfeld posted v6 of the WireGuard patch set on September 25.

Zinc is still awaiting an ack from Xu, though it is not clear how much he has scrutinized the code at this point. Once that happens, though, the networking side of the patch set can be reviewed by Miller and other networking developers. If all goes well, it will end up in the mainline before too long—but that still means at least four, or more likely seven, months from now. Whenever it comes, it is clear that WireGuard is eagerly anticipated by many.