> On Apr 28, 2022, at 9:12 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Thu, 2022-04-28 at 11:49 +0300, Boris Pismenny wrote: >> On 18/04/2022 19:49, 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. >>> >> >> Thanks for posting this. As we discussed offline, I think this approach >> is more manageable compared to a full in-kernel TLS handshake. A while >> ago, I've hacked around TLS to implement the data-path for NVMe-TLS and >> the data-path is indeed very simple provided an infrastructure such as >> this one. >> >> Making this more generic is desirable, and this obviously requires >> supporting multiple listeners for multiple protocols (TLS, DTLS, QUIC, >> PSP, etc.), which suggests that it will reside somewhere outside of net/tls. >> Moreover, there is a need to support (TLS) control messages here too. >> These will occasionally require going back to the userspace daemon >> during kernel packet processing. A few examples are handling: TLS rekey, >> TLS close_notify, and TLS keepalives. I'm not saying that we need to >> support everything from day-1, but there needs to be a way to support these. >> >> A related kernel interface is the XFRM netlink where the kernel asks a >> userspace daemon to perform an IKE handshake for establishing IPsec SAs. >> This works well when the handshake runs on a different socket, perhaps >> that interface can be extended to do handshakes on a given socket that >> lives in the kernel without actually passing the fd to userespace. If we >> avoid instantiating a full socket fd in userspace, then the need for an >> accept(2) interface is reduced, right? > > JFYI: > For in kernel NFSD hadnshakes we also use the gssproxy unix socket in > the kernel, which allows GSSAPI handshakes to be relayed from the > kernel to a user space listening daemon. > > The infrastructure is technically already available and could be > reasonably simply extended to do TLS negotiations as well. To fill in a little about our design thinking: We chose not to use either gssproxy or gssd for the TLS handshake prototype so that we don't add a dependency on RPC infrastructure for other TLS consumers such as NVMe. Non-RPC consumers view that kind of dependency as quite undesirable. Also, neither of those existing mechanisms helped us address the issue of passing a connected socket endpoint. listen/poll/accept/close addresses that issue quite directly. -- Chuck Lever
