linux-kernel - Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

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: <CAK8P3a0sFKB0Zs=R_Ban7R-Xgydd4ptxmPj03fS7B364abkOHg@mail.gmail.com>
Date:   Wed, 20 Dec 2017 22:31:08 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        James Morris <james.l.morris@...cle.com>,
        Richard Biener <rguenther@...e.de>,
        Jakub Jelinek <jakub@....gnu.org>,
        "David S. Miller" <davem@...emloft.net>,
        linux-crypto@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

On Wed, Dec 20, 2017 at 10:14 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 20 December 2017 at 20:52, Arnd Bergmann <arnd@...db.de> wrote:
>
> You can use the tcrypt.ko module to benchmark AES.
>
> modprobe tcrypt mode=200 sec=1

Ok, that's what I was looking for. I don't think I'll have time to
analyze this before
my Christmas break (I'm only here one more day, and have not set up a test
environment for this)

> to run a (lengthy) AES benchmark in various modes. AES-128 in ECB mode
> using the largest block size tested is what I usually use for
> comparison.
>
> On my Cortex-A57, the generic AES code runs at ~18 cycles per byte.
> Note that we have alternative scalar implementations on ARM and arm64
> that are faster so the performance of aes-generic is not really
> relevant (and so it is essentially dead code)

Ok. arm64 is also the least affected by this problem out of all architectures,
but it most architectures don't have an optimized implementation.

      Arnd