Date: Wed, 20 May 2020 14:58:37 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@mit.edu> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, 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: <QB1PR01MB364974A924869F9B6B254174DDB60@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200520045947.GX58497@kduck.mit.edu> 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> <QB1PR01MB3649B6EB237AE6392DF78A2EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <20200520045947.GX58497@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A= >On Tue, May 12, 2020 at 02:32:29PM +0000, Rick Macklem wrote:=0A= >> Benjamin Kaduk wrote:=0A= >> [stuff snipped]=0A= >> >You can avoid having to play games with putting stuff back on the socke= t=0A= >> >receive buffer by using a custom BIO implementation in userspace that k= nows=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 applica= tion=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-app= lication=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 b= een=0A= >> looking at soreceive_generic() recently.=0A= >> I'm guessing that a custom BIO would need to be written and the upstream= ed=0A= >> to openssl?=0A= >=0A= >It doesn't have to be upstreamed; the idea of the API is that it's modular= =0A= >and anyone can slot in their own implementation for their particular=0A= >communication needs.=0A= Well, I've already done MSG_TLSAPPDATA (a kernel only flag for soreceive())= and=0A= it seems to work fine. It makes soreceive() return an error instead of the= =0A= non-application data record, when that is what is at the head of the receiv= e queue.=0A= It is pretty straightforward, so unless someone has a problem with putting = that=0A= in head someday, I'm happy with it.=0A= =0A= I now seem to have upcalls for non-application data records working ok=0A= for both client and server.=0A= When the upcalls happen, the daemon just does a SSL_read(..,0), which seems= =0A= to work fine sofar. (Thanks go to Ben for that hint.)=0A= =0A= Thanks everyone, for your helpful comments, rick=0A= =0A= -Ben=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB364974A924869F9B6B254174DDB60>