On Mon, 18 Apr 2022 12:49:50 -0400 Chuck Lever wrote: > In-kernel TLS consumers need a way to perform a TLS handshake. In > the absence of a handshake implementation in the kernel itself, a > mechanism to perform the handshake in user space, using an existing > TLS handshake library, is necessary. > > I've designed a way to pass a connected kernel socket endpoint to > user space using the traditional listen/accept mechanism. accept(2) > gives us a well-understood way to materialize a socket endpoint as a > normal file descriptor in a specific user space process. Like any > open socket descriptor, the accepted FD can then be passed to a > library such as openSSL to perform a TLS handshake. > > This prototype currently handles only initiating client-side TLS > handshakes. Server-side handshakes and key renegotiation are left > to do. > > Security Considerations > ~~~~~~~~ ~~~~~~~~~~~~~~ > > This prototype is net-namespace aware. > > The kernel has no mechanism to attest that the listening user space > agent is trustworthy. > > Currently the prototype does not handle multiple listeners that > overlap -- multiple listeners in the same net namespace that have > overlapping bind addresses. Create the socket in user space, do all the handshakes you need there and then pass it to the kernel. This is how NBD + TLS works. Scales better and requires much less kernel code.