[openssl-dev] Questions about ASYNC API for engines and moving read buffer.

Emeric Brun ebrun at haproxy.com
Fri Jun 2 14:20:55 UTC 2017


Hi Matt,

On 06/02/2017 01:26 PM, Emeric Brun wrote:
> Hi Matt,
> 
> On 06/02/2017 12:40 PM, Matt Caswell wrote:
>>
>>
>> On 02/06/17 11:00, Emeric Brun wrote:
>>> Hi,
>>>
>>> I'm working on an ASYNC engine designed to offload crypto on multiple thread for monoproc applications.
>>>
>>> No issue on asymetric crypto part but i'm facing a problem concerning ciphers:
>>>
>>> When an SSL_read operation perform a do_cipher decrypt:
>>>
>>> My engine defer the do_cipher to be processed by an other thread using the output buffer provided by to the do_cipher method.
>>>
>>> After that it performs an ASYNC_pause_job(). On the application side it results on a WANT_ASYNC error.
>>>
>>> The application consider that nothing was written on its output, and the buffer read buffer is reused for something else.
>>>
>>> SSL_read is called a second time after receiving the event on the async fd. But this time the app used a different buffer.
>>>
>>> On the engine side, i don't see any change on the do_cipher output buffer which would allow to manage the issue with a memcopy.
>>>
>>> So my question is:
>>>
>>> Is there a way to perform ciphering with an ASYNC engine when the app don't reuse the same buffer.
>>
>> No, the async operation is running in it own fibre which is initialised
>> on first call, so it is still using the arguments from that initial
>> call. Subsequent calls won't "see" any changes in those args. We should
>> probably be more explicit about that in the docs.
>>
>> Matt
>>
> 
> I see that you're using EVP_CIPH_FLAG_PIPELINE in the dasync engine and that you're calling
> do_cipher to write in pipe_ctx->outbufs[i]. I also know that intel's qat uses such interface.
> 
> Where points these buffers? directly to the read buffer provided during the first SSL_read call
> or are they temporary allocated buffers copied into the read buffer passed during the second
> SSL_read call?
> 
> R,
> Emeric
> 

I've just read the code and I see it is not possible.

I'm disappointed because i think that a lot of applications which are using openssl in asynchronous mode
also uses SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER and have ephemeral/reused/circular buffers for
both read and write operations.

As documented: SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER "make it possible to retry SSL_write() with changed buffer location"

SSL_read implicitly also support it, and since the support of openssl in our application (0.9.8), we never faced such issue. 

In my case, this is a dead end: Enabling the async mode on any engine (mine or qat), it looks good during the hanshake but it
causes buffer overflows switching in the data stage.

Is there a way for the application to disable the async mode after the asymetric stuff (handshake)? At least we could use the
new async api for that. 

R,
Emeric




More information about the openssl-dev mailing list