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] [day] [month] [year] [list]

Date:   Wed, 3 Jan 2018 21:38:30 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        Jakub Jelinek <jakub@...hat.com>,
        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>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <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, Jan 3, 2018 at 6:36 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 3 January 2018 at 16:37, Arnd Bergmann <arnd@...db.de> wrote:
>> On Fri, Dec 22, 2017 at 4:47 PM, Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>>
>> A minimal patch would be to disable UBSAN specifically for aes-generic.c
>> for gcc-7.2+ but not gcc-8 to avoid the potential stack overflow. We could
>> also force building with -Os on gcc-7, and leave UBSAN enabled,
>> this would improve performance some 3-5% on x86 with gcc-7 (both
>> 7.1 and 7.2.1) and avoid the stack overflow.
>>
>
> Can't we just disable UBSAN for that file for all GCC versions and be
> done with it? It is not a production feature, and that code is
> unlikely to change in ways where UBSAN would make a difference anyway,
> nor is it ever executed on 99.9% of systems running Linux.

It's up to Herbert in the end. I'm leaning to the -Os change in the Makefile,
since it improves the performance for the common case as well, and
once we start disabling UBSAN for performance-critical files, it becomes
a slippery slope.

I'll send the patch with the -Os change as v2, and note the ubsan-disabling
alternative in the changelog.

       Arnd