On 2 Feb 2022, at 9:12, Hannes Reinecke wrote:
Hi all,
nvme-over-tcp has the option to utilize TLS for encrypted traffic, but
due to the internal design of the nvme-over-fabrics stack we cannot
initiate the TLS connection from userspace (as the current in-kernel
TLS implementation is designed).
This leaves us with two options:
1) Put TLS handshake into the kernel (which will be quite some
discussion as it's arguably a userspace configuration)
2) Pass an in-kernel socket to userspace and have a userspace
application to run the TLS handshake.
None of these options are quiet clear cut, as we will be have to put
quite some complexity into the kernel to do full TLS handshake (if we
were to go with option 1) or will have to design a mechanism to pass
an in-kernel socket to userspace as we don't do that currently (if we
were going with option 2).
We have been discussing some ideas on how to implement option 2
(together with Chuck Lever and the NFS crowd), but so far haven't been
able to come up with a decent design.
So I would like to discuss with interested parties on how TLS
handshake could be facilitated, and what would be the best design
options here.
The proposed configd would be an option, but then we don't have that,
either :-)
Required attendees:
Chuck Lever
James Bottomley
Sagi Grimberg
Keith Busch
Christoph Hellwig
David Howells
I'm interested in this as well, and have gone down quite a rabbit-hole
of
experimental implementation for NFS. I've found the keys API to be
useful
to implement a tls_session keytype that allows kernel subsystems to
request
that userspace do the heavy lifting of establishing a TLS session and
installing the kTLS bits on the socket by passing an existing socket fd
to
userspace.
However, something more persistent than call_usermode_helper is needed,
since userspace helpers may not be able to be looked up from a
filesystem
when establishing or re-keying (or doing a number of other things) on a
TLS
session for NFS or NVMe-over-tcp.
I've got a rough idea to create a thing called a "keyagent" which would
be
an alternative to using call_usermode_helper to service request-key.
Keyagents would be persistent processes in userspace themselves
represented
by keys, and if a keyagent key is linked into a process' keyrings and
matches the requested type it is consulted to service request-key and
update
for those keys.
Ben
