> On Apr 26, 2022, at 10:55 AM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Tue, 26 Apr 2022 13:48:20 +0000 Chuck Lever III wrote: >>> 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. >> >> The RPC-with-TLS standard allows unencrypted RPC traffic on the connection >> before sending ClientHello. I think we'd like to stick with creating the >> socket in the kernel, for this reason and for the reasons Hannes mentions >> in his reply. > > Umpf, I presume that's reviewed by security people in IETF so I guess > it's done right this time (tm). > Your wording seems careful not to imply that you actually need that, > tho. Am I over-interpreting? RPC-with-TLS requires one RPC as a "starttls" token. That could be done in user space as part of the handshake, but it is currently done in the kernel to enable the user agent to be shared with other kernel consumers of TLS. Keep in mind that we already have two real consumers: NVMe and RPC-with-TLS; and possibly QUIC. You asserted earlier that creating sockets in user space "scales better" but did not provide any data. Can we see some? How well does it need to scale for storage protocols that use long-lived connections? Also, why has no-one mentioned the NBD on TLS implementation to us before? I will try to review that code soon. > This set does not even have selftests. I can include unit tests with the prototype. Someone needs to educate me on what is the preferred unit test paradigm for this type of subsystem. Examples in the current kernel code base would help too. > Plus there are more protocols being actively worked on (QUIC, PSP etc.) > Having per ULP special sauce to invoke a user space helper is not the > paradigm we chose, and the time as inopportune as ever to change that. When we started discussing TLS handshake requirements with some community members several years ago, creating the socket in kernel and passing it up to a user agent was the suggested design. Has that recommendation changed since then? I'd prefer an in-kernel handshake implementation over a user space one (even one that is sharable amongst transports and ULPs as my proposal is intended to be). However, so far we've been told that an in-kernel handshake implementation is a non-starter. But in the abstract, we agree that having a single TLS handshake mechanism for kernel consumers is preferable. -- Chuck Lever
