Date: Thu, 27 Feb 2020 16:53:58 -0800 From: Benjamin Kaduk <bjkfbsd@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Rick Macklem <rmacklem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient Message-ID: <CAJ5_RoC_ffhmrR2M7dsRy_bYdGYZa_NmeM7z=ckcpBqybOrhMA@mail.gmail.com> In-Reply-To: <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org> References: <202002172110.01HLAXZY003012@repo.freebsd.org> <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 27, 2020 at 4:49 PM John Baldwin <jhb@freebsd.org> 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. > > Yes, you need to check the record type. I assume that kTLS is still going to pass you TLS handshake records (e.g., TLS 1.3 session tickets) that should be processed by openssl. (Hmm, TLS 1.3 KeyUpdate might present a synchronization problem, though I am not sure how kTLS is set up for that.) -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoC_ffhmrR2M7dsRy_bYdGYZa_NmeM7z=ckcpBqybOrhMA>