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]

Message-ID: <AM4PR0501MB2723C23EAC7467B09587C2C9D45E0@AM4PR0501MB2723.eurprd05.prod.outlook.com>
Date:   Tue, 31 Oct 2017 07:39:08 +0000
From:   Ilya Lesokhin <ilyal@...lanox.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sd@...asysnail.net" <sd@...asysnail.net>,
        Boris Pismenny <borisp@...lanox.com>,
        "davejwatson@...com" <davejwatson@...com>
Subject: RE: Using the aesni generic gcm(aes) aead in atomic context

On Tuesday, October 31, 2017 9:33 AM, Herbert Xu wrote:
> You are right.  generic-gcm-aesni is completely broken.
> 
> It needs to be rewritten to use a wrapper as is done with rfc4106.

I think we should consider having a synchronous implementation that falls back
to integer implementation when the FPU is not available.
This would spare the users from having to handle the asynchronous case.

Hopefully the situation where the FPU is not available is rare enough 
So it won't hurt the performance too much.