Thank you very much, David, In general, if the application use "select/poll" system function to check the readable of underline BIO and invoke the SSL_read/SSL_write only if there are data available on the socket, can the deadlock still happened?
Specially, in your last statement "At step 3 above, the reader thread is now blocking waiting for the renegotiation data to arrive on the socket. But that renegotiation data has already been received and read by the SSL engine. So the thread will block indefinitely waiting for something that has already happened.", the question is that if the underline socket is non-blocking and the application is using select/poll to check the readable of SSL connection and then invoke the SSL_write/SSL_read call, can this deadlock still happen? Thanks Bob -----Original Message----- From: David Schwartz [mailto:dav...@webmaster.com] Sent: Monday, March 07, 2011 3:43 PM To: openssl-users@openssl.org Cc: Yan, Bob Subject: Re: SSL_ERROR_WANT_READ and SSL_ERROR_WANT-WRITE question On 3/7/2011 2:45 PM, Yan, Bob wrote: > My question is that if my Reader thread gets a SSL_ERROR_WANT_WRITE > error from SSL_read function call, can my Writer thread do the > SSL_write operation right after the Reader's SSL_read operation? Yes. > Or, if my Writer > thread gets a SSL_ERROR_WANT_READ error from SSL_write call, can my > Reader thread do the SSL_read just following the Writer's SSL_write > operation? Yes. > Basically is that ok to mix the SSL_read and SSL_write > function by two different threads regardless the returning error code? Yes, there is one very important caveat though -- an SSL connection has one and only one state. So the following sequence of operations will get you in big trouble: 1) Reader thread calls SSL_write, gets WANT_READ. 2) Writer thread calls SSL_read, gets WANT_READ. 3) Reader thread (not knowing what happened in step 2) calls 'select' or similar function in response to the WANT_READ it got in step 1 and does not call SSL_write again until the socket is readable. After step 2, the state of the SSL connection is 'data must be read from the socket in order to read from the SSL connection'. It is an error to assume that the WANT_READ returned in step 1 is still valid since step 2 may have invalidated it. This can cause your code to deadlock in real world situations. For example, supposed the SSL connection is in the process of renegotiating: At step 1 above suppose it has sent the last thing it needed to send to complete the renegotiation and now it just must read the last bit of renegotiation data before it can continue to make further forward progress. So it returns WANT_READ. At step 2 above, the engine knows it needs to read from the socket to make further progress, so it does. Suppose the renegotiation data has all arrived and it reads all of it, but there's no application data to read, so it returns WANT_READ. At step 3 above, the reader thread is now blocking waiting for the renegotiation data to arrive on the socket. But that renegotiation data has already been received and read by the SSL engine. So the thread will block indefinitely waiting for something that has already happened. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
