linux-kernel - Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

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: <CAHk-=wgXHhN5MSOLeE_7rMPoGknrSxmOOJVLBa4jkz38J4gHgg@mail.gmail.com>
Date:   Fri, 21 Aug 2020 14:39:16 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Dávid Bolvanský <david.bolvansky@...il.com>,
        Eli Friedman <efriedma@...cinc.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Tony Luck <tony.luck@...el.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Joe Perches <joe@...ches.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Daniel Axtens <dja@...ens.net>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Yury Norov <yury.norov@...il.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Bruce Ashfield <bruce.ashfield@...il.com>,
        Marco Elver <elver@...gle.com>,
        Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@...il.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

On Fri, Aug 21, 2020 at 12:57 PM Arvind Sankar <nivedita@...m.mit.edu> wrote:
>
> Look, four stores into memset(), yeah that's a bit weird. I didn't think
> you meant "four" literally. But in any case, that has nothing to do with
> the topic at hand. It would be just as bad if it was a 16-byte structure
> being initialized with an out-of-line memset() call.

Actually, I mis-remembered. It wasn't four stores.

It was two.

We have this lovely "sas_ss_reset()" function that initializes three
fields in a structure (two to zero, one to '2').

And we used it in a critical place that didn't allow function calls
(because we have magic rules with the SMAP instructions).

And clang turned the initalization into a memset().  Which then
triggered our "you can't do that here" check on the generated code.

This is the kind of special rules we sometimes can have for code
generation, where the compiler really doesn't understand that no, you
can't just replace this code sequence with a function call, because
there are things going on around it that really mean that the code
should be generated the way we wrote it.

> But coming back to the actual topic: it is fine if the compiler turns
> four stores into __builtin_memset(). A size-16 or -32 __builtin_memset()
> will get inlined anyway. There's a lot of garbage here if you look
> closely: check out what gcc does to initialize a 7-character array with
> zeros at -Os.

Yeah. The reason we had to make -Os be a non-preferred thing is
because gcc has some really sad things it does when optimizing for
size.

I happen to believe that I$ matters, but -Os made _such_ a mess of
things that it was untenable to use ;(

              Linus