Subject: Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

From: Eric Biggers <[email-masked]>
Date: Tue, 11 Jul 2017 13:24:02 -0700

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, that means the CRYPTO_ALG_ASYNC bit is required to be 0, i.e. the algorithm
must be synchronous.  Currently it's requesting either a synchronous or
asynchronous algorithm, and it will crash if it gets an async one.

Also I think even with a synchronous algorithm, tls_do_encryption() still needs
to call aead_request_set_callback(), passing NULL for the callback and data, so
that the request flags are initialized.

Eric