Date: Sun, 16 Aug 2020 15:42:14 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: review of a change to sosend_generic() Message-ID: <QB1PR01MB3364DDFDB22BBC148BCA078EDD5E0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
Hi,=0A= =0A= I put D25923 up on phabricator a little while ago.=0A= I clicked on a couple of people that I thought might like to=0A= review it.=0A= =0A= However, if anyone else would like to review it, please do so.=0A= The review is as much about the concept as the actual implementation.=0A= =0A= Thanks, rick=0A= =0A= Here is the description of it...=0A= The kernel RPC cannot process non-application data records when=0A= using TLS. It must to an upcall to a userspace daemon that will=0A= call SSL_read() to process them.=0A= =0A= This patch adds a new flag called MSG_TLSAPPDATA that the kernel=0A= RPC can use to tell sorecieve() to return ENXIO instead of a non-applicat= ion=0A= data record, when that is what is at the top of the receive queue.=0A= =0A= The code could use any error return that is not normally returned by=0A= soreceive(). If some other errno is preferred, that can easily be changed= .=0A= =0A= I also put the code in #ifdef KERN_TLS/#endif, although it will build wit= hout=0A= that, so that it is recognized as only useful when KERN_TLS is enabled.= =0A= =0A= The alternative to doing this is to have the kernel RPC re-queue the=0A= non-application data message after receiving it, but that seems more=0A= complicated and might introduce message ordering issues when there=0A= are multiple non-application data records one after another.=0A= =0A= I do not know what, if any, changes will be required to support TLS1.3.= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3364DDFDB22BBC148BCA078EDD5E0>