Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear  Matt,

On Thu, Oct 8, 2015 at 10:06 PM, Matt Caswell  wrote:

>
>
> On 08/10/15 18:56, Dmitry Belyavsky wrote:
>
> > The second problem is entirely engine dependant. It will be a
> different
> > solution for different hardware. These patches do not provide a
> solution
> > to that problem.
> >
> >
> > So I do not understand what you mean by "offload" :-(
> >
> > I understand that it's an engine-dependent, but I can't imagine a
> > corresponding pseudo code.
>
> Ok. So this is the pseudo code I posted before for how an engine might
> be implemented:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
>
> So lets imagine an engine that works via threads and how those pseudo
> code function call might be implemented. It could be something like this:
>
> void initialise_engine(void)
> {
> start_thread(worker_main);
> }
>
> static int nextjobid = 0;
>
> struct work_st {
> int jobid;
> EVP_CIPHER_CTX *ctx;
> unsigned char *out;
> unsigned char *in;
> size_t inl;
> int ret;
> }
>
> int worker_main(void)
> {
> struct work_st *work;
>
> while(true) {
> work = get_work_off_in_queue();
> /* This is a long running operation */
> work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
> work->inl);
> put_work_in_finished_set(work);
> }
> }
>
> int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
> unsigned char *in, size_t inl) {
> struct work_st *work;
>
> work = malloc(sizeof *work);
> work->ctx = ctx;
> work->out = out;
> work->in = in;
> work->inl = inl;
> work->jobid = nextjobid++;
>
> add_work_to_in_queue(work);
>
> return work->jobid;
> }
>
> int work_not_finished_yet(int jobid)
> {
> return !is_work_in_finished_set(jobid);
> }
>
> int get_results_from_hardware(int jobid)
> {
> struct work_st *work;
>
> work = get_work_out_of_finished_set(jobid);
>
> return work->ret;
> }
>
> In a hardware based engine everything in "worker_main" would be
> implemented in the hardware. So the hardware gets on with the long
> running crypto operation, whilst in the software control has returned
> back to the application.
>
> Does that make more sense?
>

Thank you! I finally got it.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 18:56, Dmitry Belyavsky wrote:

> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
> 
> 
> So I do not understand what you mean by "offload" :-(
> 
> I understand that it's an engine-dependent, but I can't imagine a
> corresponding pseudo code.

Ok. So this is the pseudo code I posted before for how an engine might
be implemented:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}


So lets imagine an engine that works via threads and how those pseudo
code function call might be implemented. It could be something like this:

void initialise_engine(void)
{
start_thread(worker_main);
}

static int nextjobid = 0;

struct work_st {
int jobid;
EVP_CIPHER_CTX *ctx;
unsigned char *out;
unsigned char *in;
size_t inl;
int ret;
}

int worker_main(void)
{
struct work_st *work;

while(true) {
work = get_work_off_in_queue();
/* This is a long running operation */
work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
work->inl);
put_work_in_finished_set(work);
}
}

int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
unsigned char *in, size_t inl) {
struct work_st *work;

work = malloc(sizeof *work);
work->ctx = ctx;
work->out = out;
work->in = in;
work->inl = inl;
work->jobid = nextjobid++;

add_work_to_in_queue(work);

return work->jobid;
}

int work_not_finished_yet(int jobid)
{
return !is_work_in_finished_set(jobid);
}

int get_results_from_hardware(int jobid)
{
struct work_st *work;

work = get_work_out_of_finished_set(jobid);

return work->ret;
}

In a hardware based engine everything in "worker_main" would be
implemented in the hardware. So the hardware gets on with the long
running crypto operation, whilst in the software control has returned
back to the application.

Does that make more sense?

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell  wrote:

>
>
> No. I think you are confusing two different things.
>
> 1) How does an *application* perform asynchronous work (via libssl or
> libcrypto) using an asynchronous capable engine?
>

Ok. There is an example an explanation you have provided.


>
> 2) How does an asynchronous capable engine offload async work to its
> hardware?
>
> These patches solve the first problem only. It provides an API and
> mechanism for control to pass between the application and engine and
> back again (perhaps multiple times) during the invocation of a long
> running crypto operation. It also provides some mechanisms to enable an
> engine to signal the completion of work to the application.
>


> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
>

So I do not understand what you mean by "offload" :-(

I understand that it's an engine-dependent, but I can't imagine a
corresponding pseudo code.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 12:18, Dmitry Belyavsky wrote:
> 
> I see. So am I correct supposing that pseudo code for
> offload_cipher_to_hardware looks like this:
> 
> static int async_wrapper(void * args)
> {
> ...
> }
> 
> static ASYNC_JOB *offload (void *args)
> {
>   ASYNC_JOB *pjob = NULL;
>   int funcret;
>   size_t size = 0;
> 
>   int ret = ASYNC_start_job(&pjob, &funcret, async_wrapper, args, 
>   *args, size);
>   if (ret != ASYNC_PAUSE) return NULL;
>   return pjob;
> }
> 
> ?

No. I think you are confusing two different things.

1) How does an *application* perform asynchronous work (via libssl or
libcrypto) using an asynchronous capable engine?

2) How does an asynchronous capable engine offload async work to its
hardware?

These patches solve the first problem only. It provides an API and
mechanism for control to pass between the application and engine and
back again (perhaps multiple times) during the invocation of a long
running crypto operation. It also provides some mechanisms to enable an
engine to signal the completion of work to the application.

The second problem is entirely engine dependant. It will be a different
solution for different hardware. These patches do not provide a solution
to that problem.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 1:56 PM, Matt Caswell  wrote:

>
> > The engine needs to have a way of offloading the work to "something
> > else" so that it can come back and pick up the results later.
> Typically
> > for an engine this would mean some external hardware, but as I
> suggested
> > above it could be done using threads.
> >
> > From an engine perspective the work would be:
> > - Receive a request to do some crypto work in the normal way via the
> > engine API.
> > - Offload the work to "something else"
> >
> >
> > So what is a mechanism of such an offload? Can I, for example, get the
> > (global) ASYNC_pool and add a job (function/pointer to context) to it?
>
> The offload mechanism is entirely engine specific. We do not know how
> any specific engine works or how to interface to the hardware. An engine
> will be called in exactly the same way as now. The job of the engine
> will be to take the parameters passed to it and initiate the work in the
> engine hardware.
>
> So in pseudo code it might look something like this:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
> You will note that ASYNC_pause_job() does *not* do a "return" to return
> control back to the user application...but calling ASYNC_pause_job()
> will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
> nonetheless. The async job has its own private stack to enable this.
> Recalling SSL_read from the user application will appear to the engine
> like the function call ASYNC_pause_job() has returned.
>
>
> > How will the SSL struct obtain a job id from the engine implementing,
> > for example, "long" RSA_METHOD?
>
> It does not need to. The SSL object has a reference to the ASYNC_JOB.
> The engine can manage its own job ids - see the pseudo code above.
>

I see. So am I correct supposing that pseudo code for
offload_cipher_to_hardware looks like this:

static int async_wrapper(void * args)
{
...
}

static ASYNC_JOB *offload (void *args)
{
  ASYNC_JOB *pjob = NULL;
  int funcret;
  size_t size = 0;

  int ret = ASYNC_start_job(&pjob, &funcret, async_wrapper, args,
  *args, size);
  if (ret != ASYNC_PAUSE) return NULL;
  return pjob;
}

?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 11:26, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> I have some questions.
> 
> On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively 
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async 
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them 
> asynchronously?
> 
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
> 
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
> 
> 
> So what is a mechanism of such an offload? Can I, for example, get the
> (global) ASYNC_pool and add a job (function/pointer to context) to it?

The offload mechanism is entirely engine specific. We do not know how
any specific engine works or how to interface to the hardware. An engine
will be called in exactly the same way as now. The job of the engine
will be to take the parameters passed to it and initiate the work in the
engine hardware.

So in pseudo code it might look something like this:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}

You will note that ASYNC_pause_job() does *not* do a "return" to return
control back to the user application...but calling ASYNC_pause_job()
will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
nonetheless. The async job has its own private stack to enable this.
Recalling SSL_read from the user application will appear to the engine
like the function call ASYNC_pause_job() has returned.


> How will the SSL struct obtain a job id from the engine implementing,
> for example, "long" RSA_METHOD?

It does not need to. The SSL object has a reference to the ASYNC_JOB.
The engine can manage its own job ids - see the pseudo code above.

>  
> 
> 
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
> 
> 
> So do I understand correctly that if I want to perform SSL operations
> asynchronously, 
> I'm able to wrap the SSL functions into the application defined
> functions and then behave as described
> herein before? 

If you are doing SSL operations you do not need to wrap them in a
function as described above (although you could do if you wanted to).
libssl will do all of this for you. You only have to define your own
function for the job if you are calling libcrypto directly. For an
application doing SSL it will work very much like non-blocking IO works
today.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

I have some questions.

On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell  wrote:

>
>
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them asynchronously?
>
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
>
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
>

So what is a mechanism of such an offload? Can I, for example, get the
(global) ASYNC_pool and add a job (function/pointer to context) to it?


> - Call the new API function ASYNC_pause_job(). This will return control
> back to the calling application.
>


> - At sometime later, preferably when the application knows the work has
> completed (* see below), the application will resume the async job. From
> an engine perspective this just appears as the ASYNC_pause_job()
> function call returning - so it just continues where it left off
> - The engine should verify that the work offloaded to "something else"
> has completed.
> - If not it just calls ASYNC_pause_job() again as before.
> - If it has completed then it collects the results and returns them back
> in the normal way for an engine
>
> From an application perspective it depends whether it is using libcrypto
> directly, or whether it is using libssl.
>
> If libssl then:
> - the application essentially operates as normal
> - additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
> set the SSL_ASYNC_MODE
> - In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
> be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
> essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
> i.e sometime later (* see below) it recalls
> SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.
>

How will the SSL struct obtain a job id from the engine implementing, for
example, "long" RSA_METHOD?


>
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
>

So do I understand correctly that if I want to perform SSL operations
asynchronously,
I'm able to wrap the SSL functions into the application defined functions
and then behave as described
herein before?


>
>
> So the next question is how does the application know when it is ok to
> resume a job? There are two basic models:
>
> - Event based...essentially the engine signals to the application that
> the results are ready for collection
> - Polling...in this model the application will have to periodically
> restart the job to see if it is ready to be continued or not
>
> There are API calls available for the event based model. See
> ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
> SSL_get_async_wait_fd() in the documentation links I sent out previously.
>
> There is some example code in the ASYNC_start_job() documentation. You
> can also look at the source code for the dummy async engine.
>

Thank you. I've looked through them but still did not understand completely.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 21:44, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
> 
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
> 
> 
> If we have an engine executing long crypto operations, how can we adopt
> the engine and software using this engine to process them asynchronously? 

The engine needs to have a way of offloading the work to "something
else" so that it can come back and pick up the results later. Typically
for an engine this would mean some external hardware, but as I suggested
above it could be done using threads.

>From an engine perspective the work would be:
- Receive a request to do some crypto work in the normal way via the
engine API.
- Offload the work to "something else"
- Call the new API function ASYNC_pause_job(). This will return control
back to the calling application.
- At sometime later, preferably when the application knows the work has
completed (* see below), the application will resume the async job. From
an engine perspective this just appears as the ASYNC_pause_job()
function call returning - so it just continues where it left off
- The engine should verify that the work offloaded to "something else"
has completed.
- If not it just calls ASYNC_pause_job() again as before.
- If it has completed then it collects the results and returns them back
in the normal way for an engine

>From an application perspective it depends whether it is using libcrypto
directly, or whether it is using libssl.

If libssl then:
- the application essentially operates as normal
- additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
set the SSL_ASYNC_MODE
- In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
i.e sometime later (* see below) it recalls
SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.

If using libcrypto then:
- the application must determine which crypto operations it wants to
perform asynchronously. Those operations should be wrapped in an
application defined function.
- the application initiates the async job by calling ASYNC_start_job and
passing in a pointer to the function to be started as a job.
- from an engine perspective it will work in exactly the same way as for
libssl initiated crypto work.
- ASYNC_start_job may return with an ASYNC_PAUSE response. The
application can go off and do other work, and then resume the job at a
later time by recalling ASYNC_start_job.


So the next question is how does the application know when it is ok to
resume a job? There are two basic models:

- Event based...essentially the engine signals to the application that
the results are ready for collection
- Polling...in this model the application will have to periodically
restart the job to see if it is ready to be continued or not

There are API calls available for the event based model. See
ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
SSL_get_async_wait_fd() in the documentation links I sent out previously.

There is some example code in the ASYNC_start_job() documentation. You
can also look at the source code for the dummy async engine.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  wrote:

>
>
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
>
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
>

If we have an engine executing long crypto operations, how can we adopt the
engine and software using this engine to process them asynchronously?


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 16:57, Devchandra L Meetei wrote:
> 
> 
> On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell  >
> wrote:
> 
> 
> 
> libssl has been made async aware through the introduction of a new mode
> "SSL_MODE_ASYNC". The mode is set using a call to one of the existing
> functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
> calls to functions such as SSL_read/SSL_write etc, may now start
> returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
> is present). To resume you simply recall SSL_read/SSL_write in the same
> way as you would if you got an SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
> thread as the original call.
> 
>  
> Does this also mean that there will not be any libssl API change?

There are no changes to the fundamental way the libssl API works. This
is about integrating a new source of async events i.e. the capability to
asynchronously process crypto operations by pushing the work off into
some async capable engine. It's not about changing the way async events
are presented to applications in libssl.

> 
> I have been developing async calls of TLS I/O using bio pair, for instance
> for SSL_read, it is something like
> 
>> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf,
> int sz))
> 
> The cb will be called asynchronously whenever there is application data.
> 
> Will there be any such change? Such API's will make integrating OpenSSL
> with other
> async lib like libevent, libev and libuv etc.

There are no such changes planned.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Devchandra L Meetei]

Hello Mark
I have been working recently on evt ,
which is still in WIP, exposing a callback based async API's on top of
libssl.

The idea was to abstract libssl with well defined APIs that can be
integrated with libraries like libevent and libuv.

Thought It might be of interest to libevent.

On Wed, Oct 7, 2015 at 7:35 PM, Mark Ellzey  wrote:

> As a maintainer of libevent, and spending heaps of time in the ssl
> abstractions, anything to remove all the insane things you must do now for
> async io would be a reprieve of the horrors we've dealt with over the
> years.
>
> I do worry that these patches may take too much of the work away to the
> point of no decent control mechanism. When I see poll() everywhere, it
> throws up red flags.
>
> I will spend some time with the proposed patches here, and see if I can
> make libevent happy, and hopefully very less complex.
>
> Fingers crossed. Cheers!
>
> On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell  wrote:
>
>>
>>
>> On 07/10/15 14:29, Viktor Dukhovni wrote:
>> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
>> >
>> >> I have also added async support to s_server and s_client through the
>> new
>> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have
>> an
>> >> effect you will obviously also need an async engine (such as dasync)
>> >> loaded through the "-engine" flag. Note that dasync will only be loaded
>> >> dynamically and thus OpenSSL must be built "shared" for this to work.
>> >>
>> >> Documentation including some example code is available on all of this
>> here:
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>> >>
>> >> I'd be interested to hear your thoughts.
>> >
>> > Will existing applications doing non-blocking I/O with OpenSSL need
>> > to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
>> > only if they explicitly request "async mode"?
>>
>> No, they should not need to be modified. You will only get
>> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.
>>
>> >
>> > Should applications generally enable async mode because that might
>> > be beneficial down the road?  Or is this just for exotic hardware
>> > not likely to be seen in most environments?
>>
>> It will only be helpful if you have an engine capable of supporting
>> async. I can't really answer the question because I don't know how
>> common this will be. My hope is that this will become relatively common.
>> I have been toying with the idea of creating a multi-threaded async
>> engine where the engine manages a pool of threads to offload async work
>> to which would then offer true async support even if you don't have
>> specialist hardware.
>>
>> > For example, should Postfix enable "async" support?  It does timed
>> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.
>>
>> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
>> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
>> would encourage making the changes. You may want to consider making it a
>> configurable option. There is a small overhead with creating ASYNC_JOBs
>> and context switching into them when they start and finish.
>>
>> Matt
>>
>> ___
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did,” Steve Jobs
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Devchandra L Meetei]

On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell  wrote:


>
>
> libssl has been made async aware through the introduction of a new mode
> "SSL_MODE_ASYNC". The mode is set using a call to one of the existing
> functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
> calls to functions such as SSL_read/SSL_write etc, may now start
> returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
> is present). To resume you simply recall SSL_read/SSL_write in the same
> way as you would if you got an SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
> thread as the original call.
>

Does this also mean that there will not be any libssl API change?

I have been developing async calls of TLS I/O using bio pair, for instance
for SSL_read, it is something like

> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf, int
sz))

The cb will be called asynchronously whenever there is application data.

Will there be any such change? Such API's will make integrating OpenSSL
with other
async lib like libevent, libev and libuv etc.

Please forgive me if I am asking a dumb question without looking at code
changes done.

-- 
Warm Regards
--Dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Mark Ellzey]

As a maintainer of libevent, and spending heaps of time in the ssl
abstractions, anything to remove all the insane things you must do now for
async io would be a reprieve of the horrors we've dealt with over the
years.

I do worry that these patches may take too much of the work away to the
point of no decent control mechanism. When I see poll() everywhere, it
throws up red flags.

I will spend some time with the proposed patches here, and see if I can
make libevent happy, and hopefully very less complex.

Fingers crossed. Cheers!

On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell  wrote:

>
>
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> >
> >> I have also added async support to s_server and s_client through the new
> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
> >> effect you will obviously also need an async engine (such as dasync)
> >> loaded through the "-engine" flag. Note that dasync will only be loaded
> >> dynamically and thus OpenSSL must be built "shared" for this to work.
> >>
> >> Documentation including some example code is available on all of this
> here:
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
> >>
> >> I'd be interested to hear your thoughts.
> >
> > Will existing applications doing non-blocking I/O with OpenSSL need
> > to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> > only if they explicitly request "async mode"?
>
> No, they should not need to be modified. You will only get
> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.
>
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
>
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
>
> > For example, should Postfix enable "async" support?  It does timed
> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.
>
> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
> would encourage making the changes. You may want to consider making it a
> configurable option. There is a small overhead with creating ASYNC_JOBs
> and context switching into them when they start and finish.
>
> Matt
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 14:29, Viktor Dukhovni wrote:
> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> 
>> I have also added async support to s_server and s_client through the new
>> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
>> effect you will obviously also need an async engine (such as dasync)
>> loaded through the "-engine" flag. Note that dasync will only be loaded
>> dynamically and thus OpenSSL must be built "shared" for this to work.
>>
>> Documentation including some example code is available on all of this here:
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>>
>> I'd be interested to hear your thoughts.
> 
> Will existing applications doing non-blocking I/O with OpenSSL need
> to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> only if they explicitly request "async mode"?

No, they should not need to be modified. You will only get
SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.

> 
> Should applications generally enable async mode because that might
> be beneficial down the road?  Or is this just for exotic hardware
> not likely to be seen in most environments?

It will only be helpful if you have an engine capable of supporting
async. I can't really answer the question because I don't know how
common this will be. My hope is that this will become relatively common.
I have been toying with the idea of creating a multi-threaded async
engine where the engine manages a pool of threads to offload async work
to which would then offer true async support even if you don't have
specialist hardware.

> For example, should Postfix enable "async" support?  It does timed
> non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.

If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
would encourage making the changes. You may want to consider making it a
configurable option. There is a small overhead with creating ASYNC_JOBs
and context switching into them when they start and finish.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Viktor Dukhovni]

On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:

> I have also added async support to s_server and s_client through the new
> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
> effect you will obviously also need an async engine (such as dasync)
> loaded through the "-engine" flag. Note that dasync will only be loaded
> dynamically and thus OpenSSL must be built "shared" for this to work.
> 
> Documentation including some example code is available on all of this here:
> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
> 
> I'd be interested to hear your thoughts.

Will existing applications doing non-blocking I/O with OpenSSL need
to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
only if they explicitly request "async mode"?

Should applications generally enable async mode because that might
be beneficial down the road?  Or is this just for exotic hardware
not likely to be seen in most environments?

For example, should Postfix enable "async" support?  It does timed
non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev