Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAHk-=wiPeRQU_5JXCN0TLoW-xHZHp7dmrhx0wyXUSKxiCxE02Q@mail.gmail.com>
 <20200818202407.GA3143683@rani.riverdale.lan> <CAKwvOdnfh9nWwu1xV=WDbETGiabwDxXxQDRCAfpa-+kSZijb9w@mail.gmail.com>
 <CAKwvOdkA4SC==vGZ4e7xqFG3Zo=fnhU=FgnSazmWkkVWhkaSYw@mail.gmail.com>
 <20200818214146.GA3196105@rani.riverdale.lan> <df6c1da4-b910-ecb8-0de2-6156dd651be6@rasmusvillemoes.dk>
 <20200820175617.GA604994@rani.riverdale.lan> <CAHk-=whn91ar+EbcBXQb9UXad00Q5WjU-TCB6UBzVba682a4ew@mail.gmail.com>
 <20200821172935.GA1411923@rani.riverdale.lan> <CAHk-=wi8vdb+wo-DACDpSijYfAbCs135YcnnAbRhGJcU+A=-+Q@mail.gmail.com>
 <20200821195712.GB1475504@rani.riverdale.lan> <CAHk-=wgXHhN5MSOLeE_7rMPoGknrSxmOOJVLBa4jkz38J4gHgg@mail.gmail.com>
In-Reply-To: <CAHk-=wgXHhN5MSOLeE_7rMPoGknrSxmOOJVLBa4jkz38J4gHgg@mail.gmail.com>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri, 21 Aug 2020 17:12:23 -0700
Message-ID: <CAKwvOdnHZfVz8grK-SD6jTT1ggQNQ-RRduRdAG0nShqeitpgpg@mail.gmail.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        Arvind Sankar <nivedita@alum.mit.edu>,
        Masahiro Yamada <masahiroy@kernel.org>
Cc:     Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        =?UTF-8?B?RMOhdmlkIEJvbHZhbnNrw70=?= <david.bolvansky@gmail.com>,
        Eli Friedman <efriedma@quicinc.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Michal Marek <michal.lkml@markovi.net>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Tony Luck <tony.luck@intel.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Joe Perches <joe@perches.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Daniel Axtens <dja@axtens.net>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Alexandru Ardelean <alexandru.ardelean@analog.com>,
        Yury Norov <yury.norov@gmail.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        "Paul E . McKenney" <paulmck@kernel.org>,
        Daniel Kiper <daniel.kiper@oracle.com>,
        Bruce Ashfield <bruce.ashfield@gmail.com>,
        Marco Elver <elver@google.com>,
        Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Aug 21, 2020 at 2:39 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Aug 21, 2020 at 12:57 PM Arvind Sankar <nivedita@alum.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.

For more context for folks at home eating popcorn and enjoying the
show: https://github.com/ClangBuiltLinux/linux/issues/876#issuecomment-613049480.
And that was specifically with KASAN enabled and doesn't appear to be
common behavior in clang otherwise (higher threshold). Why the
heuristics change for when it seems to be more profitable to roll
assignment of contiguous members of the same struct to the same value
into a memset, and 2 longs seems to be the threshold for KASAN, I
don't know.  But I agree that should be fixed on the compiler side,
which is why I haven't been pushing the kernel workaround.

Everyone's just too busy right now; folks working on kernel sanitizers
have their hands full with KCSAN or MTE (on armv8.5) or default
initialization, and I'm trying to keep the build green (ie. this
series, well the v2 below, and
https://lore.kernel.org/lkml/20200812004308.1448603-1-nivedita@alum.mit.edu/
would be much appreciated), and get ready for plumbers, and wrap up my
intern's project, and do yearly performance reviews at my day job, and
million other things.

I've filed https://bugs.llvm.org/show_bug.cgi?id=47280 to discuss more
the ability to opt into builtins from a freestanding environment.

Now that Arvind has provided an excellent analysis of how the builtin
functionality works (bookmarked:
https://lore.kernel.org/lkml/20200821172935.GA1411923@rani.riverdale.lan/),
were there still objections to add the -fno-builtin-stpcpy flags for
clang to the Makefile?  I would like to get
https://lore.kernel.org/lkml/20200819191654.1130563-1-ndesaulniers@google.com/T/#m76c445f9645f62bc6ffc48ca26949725235688a0
landed so the build is not red for another week.
-- 
Thanks,
~Nick Desaulniers