On 07/12/17 09:20 AM, Steffen Klassert wrote:
> On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote:
> > On 07/11/17 08:29 AM, Steffen Klassert wrote:
> > > Sorry for replying to old mail...
> > > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx)
> > > > +{
> > >
> > > ...
> > >
> > > > +
> > > > + if (!sw_ctx->aead_send) {
> > > > + sw_ctx->aead_send = crypto_alloc_aead("gcm(aes)", 0, 0);
> > > > + if (IS_ERR(sw_ctx->aead_send)) {
> > > > + rc = PTR_ERR(sw_ctx->aead_send);
> > > > + sw_ctx->aead_send = NULL;
> > > > + goto free_rec_seq;
> > > > + }
> > > > + }
> > > > +
> > >
> > > When I look on how you allocate the aead transformation, it seems
> > > that you should either register an asynchronous callback with
> > > aead_request_set_callback(), or request for a synchronous algorithm.
> > >
> > > Otherwise you will crash on an asynchronous crypto return, no?
> >
> > The intention is for it to be synchronous, and gather directly from
> > userspace buffers. It looks like calling
> > crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC) is the correct way
> > to request synchronous algorithms only?
>
> Yes, but then you loose the aes-ni based algorithms because they are
> asynchronous. If you want to have good crypto performance, it is
> better to implement the asynchronous callbacks.
Right, the trick is we want both aesni, and to guarantee that we are
done using the input buffers before sendmsg() returns. For now I can
set a callback, and wait on a completion. The initial use case of
userspace openssl integration shouldn't hit the aesni async case
anyway (!irq_fpu_usable())
