TLS handshake for in-kernel consumers


Chuck Lever


Nuts and Bolts

Session Type




Overview via slides:

  • Why kernel consumers want TLS handshake (our use cases)
  • Alternative approaches to providing TLS handshake in the kernel
  • The netlink upcall and the user space agent we implemented (now upstream)
  • Thoughts on the use of TPM, NIC offload, keyrings, and other technologies

Followed by open discussion, questions, and rotten fruit projectiles.

More technically:

The SunRPC, SMB, and NVMe protocols all now support the use of TLS, and Linux implements those protocols in the kernel proper. QUICv1 is also a potential consumer of a handshake service.

The authors implemented a netlink upcall mechanism that passes an open socket to user space so that an existing library implementation of TLS handshake can be used rather than adding handshake code to the kernel. The purpose of this mechanism is to provide a handshake service for kernel consumers of TLS, it is not for use by user space applications.

We will discuss work that has already been merged upstream, starting with 3b3009ea8abb (“net/handshake: Create a NETLINK service for handling handshake requests”). During the BoF we will discuss the architecture and usage of this new mechanism in addition to kernel consumers that have already adopted the new mechanism.