Date: Tue, 12 May 2020 02:31:39 +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: <QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org> References: <202005100017.04A0Hd7I058863@repo.freebsd.org>, <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 think= ?=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 no= w).=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 what= =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 handl= e=0A= it?=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 t= hat can't sleep,=0A= so I'll have to hand it off to some other thread that can sleep when I need= to do it.=0A= =0A= Thanks for the hints, rick=0A= =0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0>