I am trying to rework a rather dreadful vendor-supplied OpenSSL
variant library to support event-driven operation in a clean way.

Unfortunately, the underlying device does "macro operations" that
can't be accomodated by the current -engine interface. But I can
live with maintaining a whole separate library that conforms to
the OpenSSL API -- I have to for two _other_ vendors' devices
already -- if I can get the code and interfaces reasonably clean.

While working on this I have noted what seems to me to be an
opportunity for improvement in the existing OpenSSL API, or
perhaps more rightly an interface that should be in the API but
is presently missing. Though we have SSL_read() and SSL_write()
and a non-blocking mode for SSL sessions, we lack SSL_poll() or
SSL_select(). At first glance this may seem unimportant -- the
documentation simply instructs the user to peek inside the
context structure, grab the underlying fd, and call select() or
poll() on it himself, being careful to always check for read *or*
write since SSL can require network writes to complete SSL reads --
but, actually, when working with hardware crypto that can return
results asynchronously, it's a problem.

The issue is, basically, that for an application that's managing
many SSL sessions at once (imagine, perhaps, 1 or 2 thousand) we
are likely to block the entire application waiting for a command
to a crypto accellerator to finish, when we could be sending or
receiving network data for other sessions in the meanwhile. This
happens even with engine but is particularly severe if the OpenSSL
API is actually supplied to the application by a modified library
that can do larger, more expensive crypto operations in one shot.

In essence, you can't run fully non-blocking because you can't do
the _cryptography_ in a non-blocking way. What you'd really like,
here *and* for engines, I think, is the ability to add one or more
fds to wait on behind the application's back.

If we were to add SSL_poll() (my preference) or SSL_select()
(perhaps more portable) to the API, the OpenSSL library could add
events to the set the application is waiting on -- so it could
wake the application up when crypto requests had finished and
SSL_read()/SSL_write() were possible. By default, these functions
could even #define or inline away in the headers to the underlying
OS poll()/select() -- but this would provide the opportunity to
replace them via poll/select methods in engines in the future.

And it would also avoid a profusion of incompatible APIs addressing
this on the part of SSL accellerator hardware vendors, which is an
actual problem causing user lock-in to particular hardware vendors
now. I should also mention that the vendor APIs I've seen for this
are uniformly quite poor, while SSL_poll() or _select() would be
pretty clean and conform generally to the way the existing API
works.

--
Thor Lancelot Simon tls@rek.tjls.com
"All of my opinions are consistent, but I cannot present them all
at once." -Jean-Jacques Rousseau, On The Social Contract
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org