Hi Thor, On Sun, 2008-03-02 at 23:21 -0500, Thor Lancelot Simon wrote: > > FWIW, this is not really the right way of implementing async support in > > openssl. "Completion" events are not always going to be related to file > > descriptors in any clear way > > Certainly if the file in question is one for a Unix device driver, and > that device driver is in use for asynchronous hardware-accellerated crypto > operations, there will, in fact, be a perfectly clear relationship.
Well, maybe in the cases you're interested in, but this is not an assumption I'm prepared to make w.r.t. abstractions. Even for crypto drivers that are fd-based, it would be lazy/inefficient for there to be a fd *per-operation* - ie. whilst a process's communication with a driver might very well be fd-based, the presence of data on that fd wouldn't necessarily indicate which asynchronous operation had completed. And even on unix, completions could occur via signals, IPC (of various forms), whatever. If openssl is to provide support for asynchronous completion, there needs to be a general interface for it. > I don't care, call it an "ENGINE-specified opaque token" if you like; but > you must be able to completion-wait on it without using threads and > condition variables, or it won't be useful to many users of the existing > non-blocking mode of the OpenSSL API. If you can't get the resource to > wait on, or can't wait on it with select() or poll() -- then you cannot > do asynchronous crypto. Sure, some kind of token representation will be required to allow the code "up top" to know there's something that needs completing before a given processing flow can continue, and that code would need to handle the cases of interest (ie. be it fd-based, signalled, a win32-message, [whatever]). My point is that the "call the exact same API with the exact same parameters to continue" semantic is unacceptable as a way of resuming. As I suggested earlier, even an fd-based mechanism could be transporting commands and completions for multiple crypto operations, so the "token" mechanism would need to include an "ASYNC_TOKEN_is_complete()" accessor - if that doesn't return TRUE, there's no point trying to resume the corresponding processing flow (a decent driver interface would allow you to associate opaque data with commands/completions that could point back to the "token" that can be resumed). > > , and besides which the SSL/TLS stack in > > openssl is not really one where you'd want to try and implement "resume" > > semantics. Ie. the "call the exact same thing again" approach sounds > > like the SSL/TLS objects get left in a "limbo" state after an > > asynchronous operation has started - I think I understand why you've > > done things this way > > We did it this way because it is *precisely what OpenSSL already requires > for any asynchronous operation that returns before completion already*. > There is no net change in semantics (these semantics are *already* required > in the case where the underlying network transport is non-blocking; you must > select for read or write per the WANT_READ or WANT_WRITE error return at the > SSL layer, but the next SSL operation you must issue is required to be the > exact same one you issued previously) merely an observation on my part that > those semantics are...perhaps not what I myself would have designed. Nor I :-) Nonetheless, I've worked through one project already (which was one too many) where the suspend/resume mechanism consisted of "calling back in to the API to resume". There are gargantuan problems associated with that. But the worst two; 1. exit paths on suspend - for every possible location where a function call is made that could in turn call other functions [and so on...] that result in an async crypto operation, there needs to be a *new* return value check for "suspend" that causes the function to exit without leaks. 2. wasted processing - when "going back in", many functions that are involved in the call-stacks that lead to potentially-async operations include functions you do not want to repeat - eg. ASN [en|de]codings, memcpy()s, lookups, [etc]. > Yes, the semantics are gory -- but they are already in place. Sorry if I > caused confusion on this point; I meant only to add a new error code > (WANT_CRYPTO in addition to the existing WANT_READ and WANT_WRITE) which > would indicate the existing semantics re retrying operations are required > (but to add an additional file descriptor to the select set), not change > the whole mechanism. Do you already have a modified openssl tree to achieve what you're talking about? If so, I I presume you have this extra WANT_CRYPTO code too. If not, how is the extra return code on it's own going to help? Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
