[openssl-dev] Adding async support

[Matt Caswell]

Hi all

A number of people have expressed interest in the async work that I have
been doing in collaboration with Intel. This has now progressed to the
point where it is going through team review. I thought some of you might
like to get early sight of this so I have pushed it to my personal
github repo (see the "main-async" branch):

https://github.com/mattcaswell/openssl

Obviously there may be some tweaks that occur during the review process
but hopefully it is stable enough to give you an idea of how it will work.

I have also opened a github pull request so you can post comments on the
code there if you wish:

https://github.com/openssl/openssl/pull/433

The idea is that async aware application code will be able to use
OpenSSL to initiate crypto operations asynchronously. In order to work
this will require the presence of an async capable engine. For example
you could imagine an engine that could initiate work on some external
hardware and enable application code to come back at some later time for
the results.

This has been implemented through the concept of an ASYNC_JOB. At the
libcrypto level an application developer would write a function that
they wish to execute asynchronously which might call a number of
different crypto operations. They can then initiate that job using a new
API call "ASYNC_start_job()". The function will then execute until the
engine (or indeed anything - it doesn't have to be in an engine; it
could be user code) calls "ASYNC_pause_job()". At this point control
returns back to the application code. The job can be resumed later
through a second call to "ASYNC_start_job()" - it will pick up where it
left off. The main restriction here is that this must be done from the
same thread as the original ASYNC_start_job() call. A flagging mechanism
has been implemented to enable application code to know whether the
async job is "ready" to be resumed.

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.

In order to enable people to test this out I have provided a "Dummy
Async" engine (dasync). This can't really do async work, but it pretends
it can :-). For certain crypto operations (currently only SHA1 and RSA)
it will call ASYNC_pause_job() at various points. Once you resume the
job it will just continue synchronously.

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.

Matt

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

[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 <ma...@openssl.org> 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 Caswell]

[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.

[Devchandra L Meetei]

On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell <ma...@openssl.org> 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

[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 <ell...@strcpy.net> 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 <ma...@openssl.org> 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

[Matt Caswell]

On 07/10/15 16:57, Devchandra L Meetei wrote:
>
>
> On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell <ma...@openssl.org

> <mailto:ma...@openssl.org>>
> wrote:<https://github.com/openssl/openssl/pull/433>

>
>
>
> 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.

[Dmitry Belyavsky]

Dear Matt, 

On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell <ma...@openssl.org> 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

[Matt Caswell]

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.

[Dmitry Belyavsky]

Dear Matt, 

I have some questions.

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

[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 <ma...@openssl.org

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.

[Dmitry Belyavsky]

Dear Matt, 

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

[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.

[Dmitry Belyavsky]

Dear Matt, 

On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell <ma...@openssl.org> 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

[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?

[Dmitry Belyavsky]

Dear  Matt, 

Thank you! I finally got it.

--

SY, Dmitry Belyavsky