Hey there,
On Wed, 15 Nov 2000, Dan Kegel wrote:
> Say, what do the existing crypto hardware devices provide in the
> way of interfaces and synchronization? Where's the best place to find out
> that kind of info? (The engine branch of OpenSSL will help, but it
> might not use all the hooks available.)
Well the sample size is not immense, but internally hardware usually
functions in an async manner, and typically the APIs/SDKs are such that
you can use the stuff in that way. I think you'll find if you delve into
the vendor_defn/ headers in the engine stuff, and look at the hw_**.c
implementations, you'll see that blocking forms of the API functions have
been used in all cases ... for obvious reasons, the alternative would be
to use the async versions, try and grab a file-descriptor (or some other
notification trick) and block on that before grabbing the operation's
results. Internally, that's probably precisely what those blocking API
functions are doing too.
> > of where the state-machine is at. Public-key ops create a problem in that
> > regard. If it is possible to code the SSL state machine to cope with
> > non-blocking IO on its encrypted streams, then it is certainly possible to
> > make it cope with a single new state that won't budge until the
> > async_public_key_op_query() returns ASYNC_OP_FINISHED.
>
> Yes, that would be the "OpenSSL way" of doing it.
Yeah, and I've just been trying to sift my way through the ssl/ code to
work out just how amenable the code is to that. In principle, no problem.
In practice, I dunno, I feel kind of violated after looking so deeply into
... *that* ...
> It's a viable approach, and one that fits OpenSSL's current paradigm.
> But it's not an especially high throughput way of doing it. I bet the
> way to get the most ops per second is to use a queued interface to the
> hardware, not an interface where you submit one op and wait for it to
> finish before you submit the next one.
Well, bear in mind that the only thing queuing *one* op and waiting
(albeit not inside the blocking API function call, which is the issue
here) is the SSL structure itself. The engine implementation could quite
happily manage hash-tables of operations and do whatever it can to expose
as much flexibility as is available from the software or hardware engine.
One SSL structure can only really have need for one public key operation
at a time anyway ... but if the API functions are non-blocking, one stream
of execution can be managing multiple SSL structures and the ENGINE being
used could quite happily (and asynchronously) be managing queues of
operations. Given that most hardware these days is quite parallel in
design - this is *necessary* to get good performance, and if you're
distributing crypto operations over a network, then it's critical that
this be possible. But until we solve the async interface problem - this
only scales on the application side by using multiple threads and
processes - and you way wish to scale your key-operation throughput a lot
further than you wish to scale your use of threads and processes.
> > to the caller if they support an async interface, but could also allow the
> > caller to discover at run-time if they support select()able file
> > descriptors, or thread/window messages (win32), or any other technique for
> > notification that operations are complete. Notification is *not* required
> > for this to be usable, but may be preferable in the calling application -
> > so the caller could check these capabilities too before electing whether
> > to switch the async support on or not.
>
> Eww. Sounds scary. Can you elaborate a bit more on that?
Well, as an example, I may have a hardware device and a kernel driver that
doesn't support file descriptors or any other approach for "notification"
of completion. Ie. you must proactively query with the operation ID to see
if there's a result waiting for you. In such a circumstance, many
applications may simply choose not to enable the ENGINE's async mode - so
be it. OTOH: If an application is still happy with this it could flick the
switch. If you've got a number of SSL statemachines sitting in a line and
operating in just one thread using non-blocking IO - then the select()
loop (or windows message-handler, or whatever) could be driven by activity
on the file-descriptors/sockets *and* also using timeouts (or WM_IDLE in
Win32?) to check up on SSL statemachines that were last left with an async
public key operation in progress. That's not hard to do, and doesn't
require hardware/driver/engine notification. It certainly doesn't require
bug-ugly surrender contexts, or the use of callbacks and/or signal
handlers from the engine itself when a result has arrived - in fact, such
a back-to-front way of handling async operation is far more difficult to
code around safely from the application's point of view. It's far more
likely the application can figure out the time and place it most wishes to
check up on pending public key operations.
> > Well, whilst reasonable opportunties still exist to work with the existing
> > API, I prefer to explore those. For now at least. :-)
>
> Oh, sure. Be practical :-)
<grin> Sorry, you caught me at a weak moment, what was I thinking?
> My API proposal was meant to generate discussion. I realize it's not an
> especially practical direction to move OpenSSL in. Does the idea of
> an event-driven SSL API appeal to anybody, at least in the abstract?
Well, we nearly have a purely non-blocking model available to us, were it
not that sometimes our API calls just hang waiting for public key
operations to return. And with a slick non-blocking model, it's not that
hard to build an event-driven wrapper around the outside. Presumably your
events are either network (or more precisely, SSL communication channel)
IO events, user-side events (ie. the clean side of the SSL), public-key
events (if the ENGINE supports a satisfactory form of them and you switch
it on), or application events (eg. force a renegotiate, close the SSL,
suck out cert, session, cipher details, etc). You could do that right on
top of an async state-machine without too much trouble.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
