svn commit: r360859 - projects/nfs-over-tls/sys/rpc

[Rick Macklem]

Benjamin Kaduk wrote:
>On Tue, May 12, 2020 at 02:32:29PM +0000, Rick Macklem wrote:
>> Benjamin Kaduk wrote:
>> [stuff snipped]
>> >You can avoid having to play games with putting stuff back on the socket
>> >receive buffer by using a custom BIO implementation in userspace that knows
>> >how to inject the received message.
>> >Rick Macklem wrote:
>> >>Actually, what might work for the krpc code is a new MSG_TLSAPPDATA
>> >>flag for soreceive_generic(), which says "if the record is not application
>> >>data, return an error". (Sort of the opposite of what you said above, but
>> >>would perform the same thing.)
>> >>This could be used for the krpc soreceive() calls, so that the non-application
>> >>data record remains on the socket's receive buffer.
>> Well, I'd find it a lot easier to implement MSG_TLSAPPDATA, since I've been
>> looking at soreceive_generic() recently.
>> I'm guessing that a custom BIO would need to be written and the upstreamed
>> to openssl?
>
>It doesn't have to be upstreamed; the idea of the API is that it's modular
>and anyone can slot in their own implementation for their particular
>communication needs.
Well, I've already done MSG_TLSAPPDATA (a kernel only flag for soreceive()) and
it seems to work fine. It makes soreceive() return an error instead of the
non-application data record, when that is what is at the head of the receive queue.
It is pretty straightforward, so unless someone has a problem with putting that
in head someday, I'm happy with it.

I now seem to have upcalls for non-application data records working ok
for both client and server.
When the upcalls happen, the daemon just does a SSL_read(..,0), which seems
to work fine sofar. (Thanks go to Ben for that hint.)

Thanks everyone, for your helpful comments, rick

-Ben