On 4/25/22 19:14, Jakub Kicinski wrote:
On Mon, 18 Apr 2022 12:49:50 -0400 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.
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.
But we can't, as the existing mechanisms (at least for NVMe) creates the
socket in-kernel.
Having to create the socket in userspace would require a completely new
interface for nvme and will not be backwards compatible.
Not to mention having to rework the nvme driver to accept sockets from
userspace instead of creating them internally.
With this approach we can keep existing infrastructure, and can get a
common implementation for either transport.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
