netdev - Re: [PATCH 11/16] esp: Use a synchronous crypto algorithm on offloading.

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:   Thu, 20 Apr 2017 12:50:29 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
CC:     David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: Re: [PATCH 11/16] esp: Use a synchronous crypto algorithm on
 offloading.

On Thu, Apr 20, 2017 at 05:52:35PM +0800, Herbert Xu wrote:
> On Thu, Apr 20, 2017 at 11:17:52AM +0200, Steffen Klassert wrote:
> >
> > I tried to use async algorithms but it lead to serveral problems.
> > The GSO layer can't handle async returns, we'd need callbacks
> > for all the GSO handlers. Also we need something where we can
> > requeue packets if the driver is busy etc.
> 
> Why would we need to requeue? As it is if you get an EBUSY on
> an IPsec packet it's simply dropped.

Yes we could do this, but the GSO problem remain.

We discussed this last year at netdevconf but could not come
up with an acceptable solutuion.

> 
> The main AES implementation on x86 is now async so I think it's
> pretty important that we support it out-of-the-box.

For now this is just a fallback to make hardware offloading
possible at all, so this is slowpath anyway. Allowing async
algorithms can (and should) be done in a second step once we
found a not too intrusive solution.