review of a change to sosend_generic()

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sun, 16 Aug 2020 15:42:14 +0000
Hi,

I put D25923 up on phabricator a little while ago.
I clicked on a couple of people that I thought might like to
review it.

However, if anyone else would like to review it, please do so.
The review is as much about the concept as the actual implementation.

Thanks, rick

Here is the description of it...
The kernel RPC cannot process non-application data records when
  using TLS.  It must to an upcall to a userspace daemon that will
  call SSL_read() to process them.
  
  This patch adds a new flag called MSG_TLSAPPDATA that the kernel
  RPC can use to tell sorecieve() to return ENXIO instead of a non-application
  data record, when that is what is at the top of the receive queue.
  
  The code could use any error return that is not normally returned by
  soreceive(). If some other errno is preferred, that can easily be changed.
  
  I also put the code in #ifdef KERN_TLS/#endif, although it will build without
  that, so that it is recognized as only useful when KERN_TLS is enabled.
  
  The alternative to doing this is to have the kernel RPC re-queue the
  non-application data message after receiving it, but that seems more
  complicated and might introduce message ordering issues when there
  are multiple non-application data records one after another.
  
  I do not know what, if any, changes will be required to support TLS1.3.

Received on Sun Aug 16 2020 - 13:42:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC