Date: Mon, 2 Mar 2020 09:34:45 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca>, Rick Macklem <rmacklem@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-projects@freebsd.org" <svn-src-projects@freebsd.org> Subject: Re: svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient Message-ID: <de3e5a30-c36a-916d-2de1-1ee4154d2782@FreeBSD.org> In-Reply-To: <YTBPR01MB33742D4B8CB9DB7107564927DDE90@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> References: <202002172110.01HLAXZY003012@repo.freebsd.org> <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org> <YTBPR01MB33742D4B8CB9DB7107564927DDE90@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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 Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?de3e5a30-c36a-916d-2de1-1ee4154d2782>