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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170712072012.GK2631@secunet.com>
Date:   Wed, 12 Jul 2017 09:20:13 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Dave Watson <davejwatson@...com>
CC:     Ilya Lesokhin <ilyal@...lanox.com>,
        Aviad Yehezkel <aviadye@...lanox.com>,
        Boris Pismenny <borisp@...lanox.com>,
        Liran Liss <liranl@...lanox.com>,
        "Matan Barak" <matanb@...lanox.com>,
        David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
        Tom Herbert <tom@...bertland.com>,
        <herbert@...dor.apana.org.au>, <linux-crypto@...r.kernel.org>,
        "Hannes Frederic Sowa" <hannes@...essinduktion.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        <nmav@...tls.org>, <fridolin.pokorny@...il.com>
Subject: Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

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.

> 
> > Also, it seems that you have your scatterlists on a per crypto
> > transformation base istead of per crypto request. Is this intentional?
> 
> We hold the socket lock and only one crypto op can happen at a time,
> so we reuse the scatterlists.

This is OK as long as the crypto happens synchronous. But as said above,
I think this is not what you want.