svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient

[Rick Macklem]

John Baldwin wrote:
>On 2/28/20 8:57 PM, Rick Macklem wrote:
>> John Baldwin wrote:
>>> On 2/17/20 1:10 PM, Rick Macklem wrote:
>>>> Author: rmacklem
>>>> Date: Mon Feb 17 21:10:32 2020
>>>> New Revision: 358053
>>>> URL: https://svnweb.freebsd.org/changeset/base/358053
>>>>
>>>> Log:
>>>>   Update nfs_clrpcops.c to handle ext_pgs mbufs, including the additional
>>>>   argument to nfscl_reqstart() to tell it if it should build ext_pgs mbufs.
>>>>
>>>>   This completes most of the conversion to support of ext_pgs mbufs, but
>>>>   there are still a couple of areas to fix.
>>>>   1 - The code that the MDS uses to do a proxy to a DS for a pNFS server.
>>>>   2 - The krpc code on the receive side. (The NFS code now handles the
>>>>       ext_pgs mbufs, but they are being created by copying the regular mbuf
>>>>       list when the NFS code gets it from the krpc.) The krpc still needs
>>>>       to be fixed so it can handle a list of ext_pgs mbufs handed to it
>>>>       by soreceive().
>>>
>>> Note that the current KTLS RX support I've worked on is a bit different in that
>>> it doesn't use ext_pgs mbufs.  Instead the socket buffer contains a list of
>>> records (OpenSSL uses recvmsg()) where there is a control mbuf with the TLS
>>> header followed by a chain of normal mbufs with the data.  As such, you will
>>> only have to construct ext_pgs mbufs for the send side.  Receive will still
>>> be getting regular mbufs.  For receive you probably want to check the TLS
>>> record type and do something (not sure?) with any non-application-data records,
>>> but otherwise just treat the payload of application-data records the same as
>>> you do for the non-TLS case.
>> Ok. I've already done the receive side code changes to handle ext_pgs mbufs
>> in the krpc/nfs code, so if it becomes easier/more efficient to put the receive
>> data in ext_pgs mbufs, that can be handled. (Someday there may be net
>> interfaces that perform better using ext_pgs mbufs?)
>>
>> Any non-data records that need to be handled by OpenSSL in userspace can
>> be passed up/handled by the daemons, similar to SSL_connect()/SSL_accept().
>>
>> Thanks for the info John, rick
>
>Ok.  After sending this, I do think it is likely that for NICs able to do TLS
>RX without TOE, TLS records may indeed arrive as ext_pgs mbufs, but by the time
>you would get them out of the socket buffer the TLS headers and trailers would
>be stripped and they would just be unmapped mbufs holding the TLS record payload.
>The TLS header would still be in a control message in the socket buffer.
Should be fine for the code I've written, so long as the pages are anonymous.
(If not, the code will need to know a way to allocate a page.)
For example, I have a function similar to m_split(), but it doesn't try to duplicate
a hdr mbuf and handles anonymous ext_pgs mbufs. When the split is in the
middle of a page, it allocates a new mbuf with a new page for the first partial
page and moves the rest of the pages to it.
(Actually, all of the functions like m_split() could be generalized to handle
 ext_pgs mbufs if there was an "allocate page" function for them and if mbufs
 with an m_len == 0 were allowed in the chain.)

>I started testing my KTLS RX software branch Friday btw (panicked right away
>of course, but it's hopefully not too far away).  For now I'm only focused on
>TLS 1.0-1.2, but will get to 1.3 eventually.  I suspect for 1.3 that early data
>will still be handled in userland and just as for KTLS TX, KTLS RX will only
>be used with the second set of keys.
John, I didn't think you ever wrote code that crashed;-)
Sounds good. Let me know when you have patch(es) to test.

Have fun with it, rick

--
John Baldwin