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 11:17:52 +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:06:17PM +0800, Herbert Xu wrote:
> On Thu, Apr 20, 2017 at 10:55:10AM +0200, Steffen Klassert wrote:
> > We need a fallback algorithm for crypto offloading to a NIC.
> > This is because packets can be rerouted to other NICs that
> > don't support crypto offloading. The fallback is going to be
> > implemented at layer2 where we know the final output device
> > but can't handle asynchronous returns fron the crypto layer.
> 
> Can you explain why we can't handle async algorithms on the fallback
> path?

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.

This would require a lot of changes in the generic code,
so I decided to use a synchronous fallback algorithm for
now.