[LSF/MM/BPF TOPIC] [LSF/MM/BPF ATTEND] TLS handshake for in-kernel consumers

[Benjamin Coddington]

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