This is a discussion on Re: Asynchronous ENGINE operation? - Openssl ; FWIW, I think we mostly agree but are attacking the general issue from different angles. On Wed, 2008-03-05 at 10:44 -0500, Thor Lancelot Simon wrote: > Well, I did not suggest that one would ever use a file descriptor per ...
FWIW, I think we mostly agree but are attacking the general issue from
On Wed, 2008-03-05 at 10:44 -0500, Thor Lancelot Simon wrote:
> Well, I did not suggest that one would ever use a file descriptor per
> operation. But, let me try again.
> Note first that that OpenSSL does not abstract I/O completion waiting
> (the API provides SSL_read(), SSL_write(), SSL_connect(), SSL_shutdown(),
> but *not* SSL_poll() or SSL_select). When I proposed correcting this,
> last year, I got a pretty strongly negative reception.
I was not involved in the discussion so am not familiar with the
arguments. However I agree that SSL_[poll|select]() would be unwise
because it presumes to make the SSL/TLS stack transport-aware, whereas
the BIO scheme is an honest (if sometimes inelegant) attempt to leave
the stack transport-agnostic. SSL/TLS can be fed data on all sides
purely from memory, and the real "transport" could come from lots of
non-fd-based sources. Eg. if you somehow didn't trust multi-user windows
(though we all know windows is 100% trustworthy so this is obviously an
outlandish proposition ...) then you could theoretically use SSL/TLS to
encapsulate message passing - ie. the ability to watch IPC would not
reveal the contents of that IPC. Hmm, I can just about smell the
presence of a numbskull who'll try to build a DRM scheme around
Just as the SSL user needs to "know" transport specifics to create BIOs
in the first place for hooking up to the SSL object, they also need to
"know" how (and on what) to wait when they see WANT_READ/WANT_WRITE
codes and so-forth. I think the same would essentially be true for the
use of asynchronous crypto. The point is to keep openssl agnostic, not
the application. (Now I've probably offended a vast array of library
fascists who will exclaim that libraries are supposed to "hide the
problem" rather than "hiding themselves from the problem" - to which I
there is a world beyond POSIX, hard to imagine as that may be.)
> Note next that there are already a nontrivial number of nontrivial
> applications using the existing non-blocking select()/poll() driven API
> to OpenSSL, despite its warts. This API *already* requires, quite
> explicitly, extracting the file descriptor from each SSL session and
> adding those descriptors to a select() or poll() set. Applications are
> already written to this API and it does not abstract completion waiting
> as you suggest it should (I happen to agree with you, but neither you
> nor I can adjust all of everyone else's code out there in the world!).
Actually I don't claim that it should abstract completion waiting, only
that the SSL/TLS API shouldn't. For one thing, async crypto will be a
libcrypto interface - not an SSL/TLS-specific interface. Just as BIOs
are a libcrypto interface.
> This API also *already* requires any operations that would block to be
> reissued at the SSL layer by retrying exactly the same operation again
> after the file descriptor for that session comes up ready with select
> or poll.
Sure, but that's because you are *not* suspended miles down a code path
that you need to find your way back to. It means the state-machine has
advanced as far as it can go and to advance further, you will need the
presence of either input on your read BIO or some drainage on your write
BIO. Those events are on the exterior of the SSL/TLS state-machine and
represent a stable state, the code-paths exit cleanly in that state and
when progress is possible, we will go down new code paths to do new
work. This is not the same as trying to pick up where you left off way
down a code-path that has not been designed with suspend-and-retry
semantics in mind. Eg. if you were calling SSL_read() when you got a
WANT_WRITE, but you then called SSL_write() - it should *not* crash.
What you're describing, about being able to replay your way down a prior
code-path, would be very hard to make robust in an equivalent way.
NB, this would be different if the SSL/TLS code had, since the
beginning, the idea of a third BIO-like dependency - ie. if the
state-machine was designed to interact with a read BIO, a write BIO, and
a crypto-interconnect. If that were the case, WANT_CRYPTO would already
exist, just like WANT_READ and WANT_WRITE. But the code is not like that
and making it like that would amount (IMHO) to a rewrite.
> I do not love this API, but it is what all the existing, non-threaded
> non-blocking OpenSSL API consumers are written to, and I think it would
> be a considerable mistake to change it now.
I quite agree.
> So, given my "note first" and "note second" I believe I have established
> that, to do non-blocking I/O in a single-threaded application with OpenSSL,
> one must already:
> 1) Dip beneath the SSL abstraction layer to get the file
> descriptor for each session.
No, this is one form it must be able to take, but this is not *the*
general method for OpenSSL to support.
> 2) Use select() or poll() to wait on all those file descriptors.
During which time the SSL/TLS object (and "token" handling) is in *what*
> 3) Retry operations, exactly as issued prior to completion waiting,
> when their sessions' descriptors come up ready in select or
> poll (whether to select for read-ready or write-ready is known
> by the WANT_READ or WANT_WRITE SSL errors returned when the
> operation would block).
I've been down this route before and the "retry" is where I lose
interest in this approach. The tree of possible code-paths that *could*
go asynchronous is frightening, and adapting them to return back up the
call-stack cleanly in a "WANT_CRYPTO" manner, as well as going back down
the call-stack to "retry" is at best going to be a usually-works hack.
And if there's one place we don't want cut-corner hacks, it's in an
SSL/TLS implementation. In other words, I've never seen CERT issue an
security advisory on the basis of design insanity, but I don't want us
pioneering in this field.
> I propose, then, to extend the existing interface to accomodate non-blocking
> operation of ENGINEs themselves, by:
I see where you're heading, and some pieces of the idea are (IMHO) going
to be part of any meaningful solution. But from a big-picture
perspective, I think you're heading down a rat-hole with this approach.
If we take openssl as it stands, and the considerable inertia associated
with its existing user-base (a valid point you made earlier), I think
the SSL/TLS implementation will just not let us go the way you're
And to your probably significant frustration, I'm not going to try and
describe what I think we should do instead. At least, not in this email.
I'm going to try and mock-up an overview of how I think openssl should
address this and I will certainly run it by you for feedback.
> Given the already existing API for non-blocking operation in OpenSSL, I
> must confess I am pretty much baffled how else it _could_ work.
I'll give you a clue, create a stack object, extend it with state about
your current context, swapcontext(3) to the new stack (or whatever
compiled-in equivalent your platform or mood provides for), call any SSL
API you like, presume that leads down to crypto code that "wants" to go
asynchronous, the async crypto code detects that async suspension has
been made *available* (the stack object stuff), set appropriate
suspension flags and swapcontext() back to the "user's" context, use the
suspension flags to glue the "token" logic so the user can know when to
go back to that SSL object, and when it's time, the retry is a
swapcontext(3) (or sigsetjmp() - read Ralf's GNU-Pth docs and/or usenix
paper if you want to know how these things work) straight back to the
Damn, there I go describing what I said I wouldn't describe yet. And
trying to do so in one sentence has no doubt rendered it completely
obscure. Anyway, the way to do this robustly with the existing openssl
code, and do so without processing waste, is to leave the call-stack
as-is when you are way down in the crypto code - you context-switch back
out to suspend and context-switch back in to resume.
The rest is details and having an interface that can port to unusual
environments (I reiterate: not just file-descriptors). The "waiting
mechanism" is really the detail of how you represent and convey that
suspension between the caller/user and the the crypto code. Moreover,
SSL/TLS is just one use-case of this mechanism, it's not
SSL/TLS-specific, it's libcrypto-specific.
More news when I have some.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org