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

[Benjamin Kaduk]

On Thu, Feb 27, 2020 at 4:49 PM John Baldwin <jhb at 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