Date: Tue, 12 May 2020 04:02:55 +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: <QB1PR01MB36494D1076388A2AD64F5B02DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <QB1PR01MB3649282401A7562B36D3F84EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> References: <202005100017.04A0Hd7I058863@repo.freebsd.org>, <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org>, <QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <QB1PR01MB3649282401A7562B36D3F84EDDBE0@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 thi= nk?=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= Actually, what might work for the krpc code is a new MSG_TLSAPPDATA=0A= flag for soreceive_generic(), which says "if the record is not application= =0A= data, return an error". (Sort of the opposite of what you said above, but= =0A= would perform the same thing.)=0A= This could be used for the krpc soreceive() calls, so that the non-applicat= ion=0A= data record remains on the socket's receive buffer.=0A= =0A= Then the krpc could do the upcall when the error is returned by soreceive()= =0A= and the userland daemon could do an SSL_read() with=0A= SSL_MODE_AUTO_RETRY turned off. If I understand the man page, that will=0A= make SSL_read() process the non-application data record but return with an= =0A= error of SSL_ERROR_WANT_READ without taking application data off the=0A= socket's receive buffer queue.=0A= --> If this all works (?), then the krpc can just go on and soreceive() the= next=0A= application data record after the upcall returns.=0A= =0A= Worth a try anyhow, I think? rick=0A= =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 = now).=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?QB1PR01MB36494D1076388A2AD64F5B02DDBE0>