LWN：扩展内核里的TLS支持！

关注了就能看到更多这么棒的文章哦～

Extending in-kernel TLS support

By Jonathan Corbet
April 25, 2022
DeepL assisted translation
https://lwn.net/Articles/892216/

内核在 2017 年 9 月推出的 4.13 版本中就支持了 TLS 协议。但这个支持是不完整的，因为它没有给内核提供一种方法来自己发起 TLS 连接。而是需要用户空间创建一个 socket，并在将 socket 交给内核之前执行 TLS 握手，然后内核可以使用 TLS 来传输数据。Chuck Lever 提出了一组 patch，可能可以改变这种情况了，尽管仍然需要用户空间来做些事情。

众所周知，TLS 是用来在网络上传输加密数据的。别的不用说，至少 HTTPS 链接背后依赖的协议就是 TLS。当前，网络上传输的数据有很大一部分是以这种方式加密的。在建立了连接之后，把数据加密发送到另一端的工作是相对比较简单的，对收到的数据进行解密也是如此。然而，建立连接的过程很复杂，其中还涉及到算法协商以及为一端或两端来提供（provision）和验证（verification）公共密钥。

在内核中支持 TLS 的话会有一些好处，包括性能会有小幅提升，并且可以使用 socket filter 来过滤了。不过，TLS session 的建立过程并不太关注性能，而且由于这个过程很复杂，可能会导致更多的 bug 以及安全问题。因此，当人们给内核添加 TLS 支持时，主要专注在数据传输方面，而将建立 session 的困难留给了用户空间。这就是内核的 TLS 支持在过去几年中的工作方式。

这个解决方案是有效的，但有时如果内核能够自己启动 TLS session 的话会很有好处。因此引出了 Lever 的 patch。这个 patch set 仍然没有将 TLS 握手引入内核，尽管最终还是希望能实现这个理想目标的：

从长远来看，我们倾向于在内核中实现 TLS 握手。然而，这还需要很长的时间，而且有些人希望在没有充分理由的情况下就不要去增加 Linux 内核的 "攻击面" 了。因此我们也同时创建了一个原型来实现握手，它会去调用到用户空间，而实际的握手工作就可以由现成的 TLS 库实现来完成。

这个设计要求在有可能需要内核启动 TLS 连接的情况下（具体来说就是所有的 network namespace 里面）运行一个特殊的用户空间进程。该进程将使用新增的 AF_TLSH（"TLS helper"）address-family type 来创建一个 socket，然后监听该 socket。当内核需要建立一个 TLS session 时，listen() 调用就会返回一个已经连接上的 TCP socket；然后该进程可以与远端的对方来交流从而建立好 session。如果协商成功就可以使用带有新增的 SOL_TLS 选项的 setockopt() 调用来配置新建立的 session。关闭 socket 后就会把它返还给内核。

在内核里面，会有一个新函数在最开始 TCP 连接建立后就被调用：

int tls_client_hello_x509(struct socket *sock, void (*done)(void *data, int status),
        void *data, const char *priorities, key_serial_t peerid,
        key_serial_t cert);

这个调用会试图把 sock 传递给 helper 进程。成功的话就会返回 0；此时仍在进行协商。等到 session 设置成功（或失败）之后，done() 这个回调函数就会被调用，并给出此操作的结果。如果得到的是一个成功的状态，那么内核就应该能够通过 socket 来使用 TLS 进行通信了。还有 tls_client_hello_psk() 函数，它可以在有 pre-shared key 密钥存在的情况下用来共享。

有人会问，为什么需要这个功能？其中之一的用途就是在 TLS 上实现远程过程调用（RPC）协议，这已经有了相关的后续 patch set。这样就可以用来在加密连接之上实现 NFS 文件系统协议了。Lever 说，未来人们可能还有兴趣使用这一功能来在 QUIC 连接之上支持 SMB 文件系统协议，当然，前提是内核在这几年确实支持了 QUIC 的话。

对 TLS patch 的反应相对平静，只有 Hannes Reinecke 的一组 Reviewed-by 标签，他也是其中一个 patch 的作者。相反，RPC-over-TLS patch 则遇到了一些来自 Trond Myklebust 的不同意见，他是内核 NFS 客户端的维护者。他认为这些 setup 工作可以完全在用户空间由 mount.nfs 工具完成。Lever 回应说，在有些情况下，我们认为内核需要决定是否应该使用 TLS。讨论结束时仍然没有得出结论，所以这个话题很可能会在 5 月初的 Linux Storage, Filesystem, and Memory-Management Summit 上继续讨论。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～