netdev - RE: Using the aesni generic gcm(aes) aead in atomic context

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]

Date:   Tue, 31 Oct 2017 09:41:24 +0000
From:   Ilya Lesokhin <ilyal@...lanox.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sd@...asysnail.net" <sd@...asysnail.net>,
        Boris Pismenny <borisp@...lanox.com>,
        "davejwatson@...com" <davejwatson@...com>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: RE: Using the aesni generic gcm(aes) aead in atomic context

On Tuesday, October 31, 2017 11:14 AM Steffen Klassert wrote:

> I think Ilya talks about the case where the TLS crypto is intended to be offloaded
> to a NIC. In this case we need a software crypto fallback e.g. if a packet got
> rerouted to a device that does not support crypto offloading. 
You are correct.
> 
> Allowing for async crypto would require some way to handle async returnes or
> the -EBUSY case from the crypto layer inside of a qdisc. Also, in the GSO case it is
> not clear how to unwind the GSO call stack on a async return.
> 
> I had a discussion with davem at the netfilter workshop about this. Based on this
> discussion, I prepared some patches that I hope to be (RFC) ready until the
> netdev2.2 next week.

Are you sure supporting ASYNC crypto for fallback is worth the trouble?
This path is going to be slower that the path were you do the crypto in advance, right?

Are you concerned about the lack of synchronous crypto implementations for some algorithms?