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

Emeric Brun ebrun at haproxy.com
Fri Jun 2 11:26:24 UTC 2017


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


More information about the openssl-dev mailing list