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

[Rick Macklem]

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?

Does anyone else (John maybe) have a preference?

>>Then the krpc could do the upcall when the error is returned by soreceive()
>>and the userland daemon could do an SSL_read() with
>>SSL_MODE_AUTO_RETRY turned off. If I understand the man page, that will
>>make SSL_read() process the non-application data record but return with an
>>error of SSL_ERROR_WANT_READ without taking application data off the
>>socket's receive buffer queue.
>
>The typical way to consume non-application-data records without hanging trying
>to read any application data is to do a zero-length read.  This still gets far enough
>into the state machine machinery to do the job before checking that the length
>is nonzero.
Oh, that's useful info. I recall trying it months ago and it didn't seem to work.
Maybe I was just seeing the failure and not realizing that it had worked but returned
failure. I'll play with this using my userland test daemons.
[most stuff snipped]
>In the early-data case things are more complicated.  Calling regular SSL_read() will
>drive the handshake to completion, and there's a separate function to call to just
>try to read early data.  (You could also configure things to fully deny early data which
>would probably be easier.)
Thanks. Good suggestion. I've never known what to do with the early data when I
played with the test daemons. (Again, I just threw it away.)

Btw, I think I can test this using TLS1.2 because when one end does SSL_shutdown(),
TLS1.2 sends an "alert close" and I can try handling that.

Thanks for the comments, rick

-Ben

I might be stuck having the daemon do an SSL_read() for one application data
record and then it can pass that data back down into the kernel to be prepended
on the queue of received application data.

>(I wouldn't want to MSG_PEEK for every record, since these will be rare.)
>I also do already have code that blocks kernel reception when the upcall
>to do the handshake is done, so the same could be used in this case.
>
>There is the slight trick that the client krpc code is in a socket upcall that can't sleep,
>so I'll have to hand it off to some other thread that can sleep when I need to do it.
>
>Thanks for the hints, rick
rick
--
John Baldwin
_______________________________________________
svn-src-projects at freebsd.org<mailto:svn-src-projects at freebsd.org> mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-projects
To unsubscribe, send any mail to "svn-src-projects-unsubscribe at freebsd.org<mailto:svn-src-projects-unsubscribe at freebsd.org>"