Date: Tue, 12 May 2020 02:52:01 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, 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: r360859 - projects/nfs-over-tls/sys/rpc Message-ID: <QB1PR01MB3649282401A7562B36D3F84EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> References: <202005100017.04A0Hd7I058863@repo.freebsd.org>, <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org>, <QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Rick Macklem wrote:=0A= >John Baldwin wrote:=0A= >>On 5/9/20 5:17 PM, Rick Macklem wrote:=0A= >>> Author: rmacklem=0A= >>> Date: Sun May 10 00:17:39 2020=0A= >>> New Revision: 360859=0A= >>> URL: https://svnweb.freebsd.org/changeset/base/360859=0A= >>>=0A= >>> Log:=0A= >>> Add some very basic handling of TLS_GET_RECORD control mbufs.=0A= >>>=0A= >>> For now, it just throws away any that are non-application data.=0A= >>> In the future, this will need to change, but not until TLS1.3, I thin= k?=0A= >>=0A= >>Ideally you'd keep an nfsd thread in userland that you could pass=0A= >>these records onto. One possible option is the thread just keeps=0A= >>calling SSL_read() but you do create a new flag on the socket buffer=0A= >>that causes soreceive() to only pass non-application data datagrams=0A= >>to userland reads() and have the in-kernel read requests block if they=0A= >>see a non-application data record as the next record until the user=0A= >>thread wakes up and reads it (or EAGAIN or whatever you need it to=0A= >>do).=0A= >Well, I currently have daemons (rpctlssd and rpctlscd) that just wait for= =0A= >upcalls from the kernel and do the SSL stuff (mainly the handshake right n= ow).=0A= >(You can guess from the names which one is RPC client vs server.;-)=0A= >I can easily do an upcall for a non-application data record if/when I need= to do so.=0A= >(The upcalls are done via Sun RPC using an AF_LOCAL socket, similar to wha= t=0A= > the gssd does.)=0A= >=0A= >For me, the mystery is what to do with it once the daemon gets it.=0A= >From what you said, I'll need to "trick" SSL_read into reading it.=0A= >Maybe I can push it back on the socket buffer receive queue in the kernel= =0A= >and then the daemon can do a SSL_read() to read it off the socket and hand= le=0A= >it?=0A= Oh, and one more little challenge...=0A= When I played around with the daemons using TLS1.3 (before there was a ktls= =0A= rx I could use), I would run into early data that would be handled by SSL_r= ead()=0A= done in userland by the daemon.=0A= However, I couldn't find a way to tell it to not wait to read any applicati= on data.=0A= I recall trying an SSL_read() for 0 bytes and it didn't like it.=0A= I might be stuck having the daemon do an SSL_read() for one application dat= a=0A= record and then it can pass that data back down into the kernel to be prepe= nded=0A= on the queue of received application data.=0A= =0A= >(I wouldn't want to MSG_PEEK for every record, since these will be rare.)= =0A= >I also do already have code that blocks kernel reception when the upcall= =0A= >to do the handshake is done, so the same could be used in this case.=0A= >=0A= >There is the slight trick that the client krpc code is in a socket upcall = that can't sleep,=0A= >so I'll have to hand it off to some other thread that can sleep when I nee= d to do it.=0A= >=0A= >Thanks for the hints, rick=0A= rick=0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3649282401A7562B36D3F84EDDBE0>