On Apr 26, 2022, at 7:47 PM, Jakub Kicinski [off-list ref] wrote:

On Tue, 26 Apr 2022 15:58:29 +0000 Chuck Lever III wrote:

quoted

quoted

On Apr 26, 2022, at 10:55 AM, Jakub Kicinski [off-list ref] wrote:

quoted

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).  

quoted

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?

I meant scale with the number of possible crypto protocols, 
I mentioned three there.

I'm looking at previous emails. The "three crypto protocols"
don't stand out to me. Which ones?

The prototype has a "handshake type" option that enables the kernel
to request handshakes for different transport layer security
protocols. Is that the kind of scalability you mean?

For TLS, we expect to have at least:

 - ClientHello
  - X509
  - PSK
 - ServerHello
 - Re-key

It should be straightforward to add the ability to service
other handshake types.

quoted

Also, why has no-one mentioned the NBD on TLS implementation to
us before? I will try to review that code soon.

Oops, maybe that thing had never seen the light of a public mailing
list then :S Dave Watson was working on it at Facebook, but he since
moved to greener pastures.

quoted

quoted

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.

Whatever level of testing makes you as an engineer comfortable
with saying "this test suite is sufficient"? ;)

For TLS we have tools/testing/selftests/net/tls.c - it's hardly
an example of excellence but, you know, it catches bugs here and 
there.

My question wasn't clear, sorry. I meant, what framework is
appropriate to use for unit tests in this area?

quoted

quoted

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?

Hm, do you remember who you discussed it with? Would be good 
to loop those folks in.

Yes, I remember. Trond Myklebust discussed this with Dave Miller
during a hallway conversation at a conference (probably Plumbers)
in 2018 or 2019.

Trond is Cc'd on this thread via linux-nfs@ and Dave is Cc'd via
netdev@.

I also traded email with Boris Pismenny about this a year ago,
and if memory serves he also recommended passing an existing
socket up to user space. He is Cc'd on this directly.

I wasn't involved at the beginning of the 
TLS work, I know second hand that HW offload and nbd were involved 
and that the design went thru some serious re-architecting along 
the way. In the beginning there was a separate socket for control
records, and that was nacked.

But also (and perhaps most importantly) I'm not really objecting 
to creating the socket in the kernel. I'm primarily objecting to 
a second type of a special TLS socket which has TLS semantics.

I don't understand your objection. Can you clarify?

AF_TLSH is a listen-only socket. It's just a rendezvous point
for passing a kernel socket up to user space. It doesn't have
any particular "TLS semantics". It's the user space agent
listening on that endpoint that implements particular handshake
behaviors.

In fact, if the name AF_TLSH gives you hives, that can be made
more generic. However, that makes it harder for the kernel to
figure out which listening endpoint handles handshake requests.

quoted

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.

For some definition of "we" which doesn't not include me?

The double negative made me blink a couple of times.

I'm working with folks from the Linux NFS community, the
Linux block community, and the Linux SMB community. We
would be happy to include you in our effort, if you would
like to be more involved.


--
Chuck Lever