[openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 14:29, Viktor Dukhovni wrote:
> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> 
>> I have also added async support to s_server and s_client through the new
>> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
>> effect you will obviously also need an async engine (such as dasync)
>> loaded through the "-engine" flag. Note that dasync will only be loaded
>> dynamically and thus OpenSSL must be built "shared" for this to work.
>>
>> Documentation including some example code is available on all of this here:
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>>
>> I'd be interested to hear your thoughts.
> 
> Will existing applications doing non-blocking I/O with OpenSSL need
> to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> only if they explicitly request "async mode"?

No, they should not need to be modified. You will only get
SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.

> 
> Should applications generally enable async mode because that might
> be beneficial down the road?  Or is this just for exotic hardware
> not likely to be seen in most environments?

It will only be helpful if you have an engine capable of supporting
async. I can't really answer the question because I don't know how
common this will be. My hope is that this will become relatively common.
I have been toying with the idea of creating a multi-threaded async
engine where the engine manages a pool of threads to offload async work
to which would then offer true async support even if you don't have
specialist hardware.

> For example, should Postfix enable "async" support?  It does timed
> non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.

If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
would encourage making the changes. You may want to consider making it a
configurable option. There is a small overhead with creating ASYNC_JOBs
and context switching into them when they start and finish.

Matt