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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
