|
请考虑订阅 LWN 订阅是 LWN.net 的生命线。 如果您喜欢这些内容并希望看到更多，您的订阅将有助于确保 LWN 继续蓬勃发展。 请访问此页面加入我们，让 LWN 继续在网络上传播。
|
作者：
Jonathan Corbet
2019年3月25日
自本文
发表以来，WireGuard 虚拟专用网络实施方案已经走过了整整一年多的时间。 自本文发表以来，WireGuard 在许多方面都取得了进步：它获得了许多满意的用户，得到了
Linus Torvalds 的认可，现在还得到了 NetworkManager 等工具的支持。 不过，有一件值得注意的事情还
没有发生：WireGuard 还没有并入主线内核。 在沉寂了一段时间后，WireGuard 又回来了，看来进入上游的漫长过程已接近尾声。
新版的 WireGuard 补丁已于 3 月 22 日发布。 WireGuard 本身并无特别争议；很少有人对其设计或实施提出抱怨。 症结在于 WireGuard 使用的"Zinc "加密库。 Zinc 的诞生源于对内核当前加密层的不满，许多人认为该加密层太难使用。 从本质上讲，Zinc 是一个全新的加密层，与当前代码并存，重复了内核中的大量功能，但为加密任务提供了一个更简单的界面。
人们对 Zinc 有一些抱怨。 其中之一就是，Zinc 不仅是一个用于访问加密算法的新 API，它还包含了自己对这些算法的实现，重复了内核已有的功能。 WireGuard 的作者 Jason Donenfeld 为这些新的实现进行了辩护，认为它们经过了更高级别的加密审查，这可能是正确的。 不过，内核开发人员非常不喜欢这种重复；他们会认为，如果特定算法的新实现更好，就应该直接取代现有算法，而不是重复。 这样，只需维护一个版本，所有用户都能享受到它带来的好处。
一段时间以来，重复算法一直是一个棘手的问题，但现在似乎有了一个解决方案。 加密货币维护者赫伯特-徐（Herbert Xu）发布了一个版本的 Zinc，其中引入了新的 API，但使用的是现有的算法实现，而不是多南菲尔德的新算法。 这样一来，像 WireGuard 这样的用户就可以使用 API，而新算法的实现则暂时不在讨论之列。 将来，我们可以根据这些算法实现本身的优点对其进行评估，并在达成共识认为它们更好时逐一合并。
以往的讨论可能会让人以为多南菲尔德会抵制这一举动，但这次他回应说："我认为我们稍微接近了同一
起跑线"。 他计划对徐的 Zinc 版本做一些修改，但他打算发布的版本仍将使用现有的内核算法。 假设大家都喜欢这样的结果，WireGuard 合并的主要长期障碍之一将被克服。
加密功能的重复并不是对 Zinc 的唯一抱怨，阿德-比舍维尔（Ard Biesheuvel）也表达了对 Zinc 的其他抱怨。 Biesheuvel 将 Zinc 描述为"分层违规
"，并抱怨它无法使用内核中的异步算法实现。 这是设计所致：Zinc 只明确支持同步实现（即调用者等待每个操作完成）。 异步实现（通常在外部加速器上并行运行，同时调用者做其他事情）被认为过于复杂，带来的好处太少。
Biesheuvel 不同意异步操作的这种观点，他担心将来会有人在 Zinc 上附加异步支持。 他更希望看到开发人员致力于修复现有加密 API 的缺陷。 持这种观点的不只他一个人，其他人也有不同意见，包括托瓦尔兹，他曾宣称自己是 Zinc 阵营的坚定支持者：
老实说，在这一点上我与杰森的观点一致。当你知道你的密码或哈希算法是什么，CPU 直接就能很好地完成时，密码/模型就很难使用，效率低下，而且完全没有意义。
他接着说："异步加速器代码在真实硬件和任何正常真实负载上都没有任何价值
。 如果异步加密加速器在现实世界中缺乏价值，那么引入一个可以有效忽略它们的应用程序接口就有一定意义了。 当然，这种对异步加密设备的看法并不被普遍认同，否则内核中就不会存在对它们的支持。 请特别参阅帕斯卡尔-范-里欧文（Pascal Van Leeuwen）对托瓦尔兹某些批评意见的反驳。 但很明显，异步加密对于各种用例来说并不是特别有用。
如果 Torvalds 所表达的观点（以及 Xu 暗含的观点）胜出，如果 Zinc 的下一篇文章能充分解决有关重复算法的问题，那么 Zinc 进入主线的道路将开始变得相对清晰。 除非 WireGuard 出现新的问题（这似乎不太可能，因为即使是反对 Zinc 的人也倾向于支持 WireGuard），否则它应该会在 Zinc 加入后立即被合并。 这样，让 WireGuard 进入主线的漫长故事就可以画上一个圆满的句号了。
(登录以发表评论)
