Date: Tue, 12 May 2020 14:32:29 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <bjkfbsd@gmail.com> Cc: 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: <QB1PR01MB3649B6EB237AE6392DF78A2EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAJ5_RoBw-vyPH1EdeKHS=a_kCm3HPoiAkpA%2BrTxhPYcqf3Lz-w@mail.gmail.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> <QB1PR01MB36494D1076388A2AD64F5B02DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <CAJ5_RoBw-vyPH1EdeKHS=a_kCm3HPoiAkpA%2BrTxhPYcqf3Lz-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A= [stuff snipped]=0A= >You can avoid having to play games with putting stuff back on the socket= =0A= >receive buffer by using a custom BIO implementation in userspace that know= s=0A= >how to inject the received message.=0A= >Rick Macklem wrote:=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 applicatio= n=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-applic= ation=0A= >>data record remains on the socket's receive buffer.=0A= Well, I'd find it a lot easier to implement MSG_TLSAPPDATA, since I've been= =0A= looking at soreceive_generic() recently.=0A= I'm guessing that a custom BIO would need to be written and the upstreamed= =0A= to openssl?=0A= =0A= Does anyone else (John maybe) have a preference?=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 a= n=0A= >>error of SSL_ERROR_WANT_READ without taking application data off the=0A= >>socket's receive buffer queue.=0A= >=0A= >The typical way to consume non-application-data records without hanging tr= ying=0A= >to read any application data is to do a zero-length read. This still gets= far enough=0A= >into the state machine machinery to do the job before checking that the le= ngth=0A= >is nonzero.=0A= Oh, that's useful info. I recall trying it months ago and it didn't seem to= work.=0A= Maybe I was just seeing the failure and not realizing that it had worked bu= t returned=0A= failure. I'll play with this using my userland test daemons.=0A= [most stuff snipped]=0A= >In the early-data case things are more complicated. Calling regular SSL_r= ead() will=0A= >drive the handshake to completion, and there's a separate function to call= to just=0A= >try to read early data. (You could also configure things to fully deny ea= rly data which=0A= >would probably be easier.)=0A= Thanks. Good suggestion. I've never known what to do with the early data wh= en I=0A= played with the test daemons. (Again, I just threw it away.)=0A= =0A= Btw, I think I can test this using TLS1.2 because when one end does SSL_shu= tdown(),=0A= TLS1.2 sends an "alert close" and I can try handling that.=0A= =0A= Thanks for the comments, rick=0A= =0A= -Ben=0A= =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= _______________________________________________=0A= svn-src-projects@freebsd.org<mailto:svn-src-projects@freebsd.org> mailing l= ist=0A= https://lists.freebsd.org/mailman/listinfo/svn-src-projects=0A= To unsubscribe, send any mail to "svn-src-projects-unsubscribe@freebsd.org<= mailto:svn-src-projects-unsubscribe@freebsd.org>"=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3649B6EB237AE6392DF78A2EDDBE0>