On Sat, Apr 14, 2007 at 02:27:42PM -0700, Nickolai Zeldovich wrote:
> Composability may be a desirable property for any asynchronous OpenSSL
> interface. Currently, it's possible to run OpenSSL with other
> event-based libraries in the same thread, by calling select() on the
> union of file descriptors from all libraries.

Not really: right now, SSL can effectively block you for as long as it
likes and there's nothing you can do about it. This makes writing real
event-driven applications with OpenSSL a non-starter.

> One alternative would be to provide a function (say,
> SSL_select_prepare) that would be called before the application code
> calls select(), which would set the appropriate bits in the
> caller-supplied fd_sets for SSL connections of interest to the
> application.

This is a good idea. But what if what SSL actually needs to do in order
to wait on the fds you're interested in, plus the cryptographic operations
for your SSL contexts, is considerably more than just adding fds to a
select set? For example, in the vendor-supplied code I maintain, the only
really practical way to wait on all the right things efficiently will be
to transform the supplied select set or pollfds into a kevent structure,
add a number of kevent elements specific to the hardware device, and wait
for notifications. I could massage the underlying code to wait
on the device's fd with poll() instead, but then I would still need to do
a second system call to get cryptographic results, then handle them
internally, before I could guarantee that a user's SSL_read() or _write()
would actually return useful results.

Basically, to run efficiently with hardware crypto, you really want the
call that waits on events to happen _in_ OpenSSL. If you just cause
stuff to be added to the application's wait set and let it do the waiting
call, you can't actually consume crypto-done and return control to the
application in an efficient way. And consumers of this interface likely
really, really care about efficiency, since if they were willing to take
the hit associated with context-switches for threading (15% on my device
at saturation with 4K SSL connections) they'd just avoid the issue by
using threads. :-/

Still, right now there is _no_ way to do this. Anything reasonably
clean, it seems to be, is better than that!

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org