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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOdnk6PrHGB-zam-aAxKG119x2o21COxjV9DnhU=WH3wjjg@mail.gmail.com>
Date:   Tue, 18 Aug 2020 16:22:09 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Eli Friedman <efriedma@...cinc.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        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>,
        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>,
        Dávid Bolvanský <david.bolvansky@...il.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

On Tue, Aug 18, 2020 at 3:05 PM Dávid Bolvanský
<david.bolvansky@...il.com> wrote:
>
> st 19. 8. 2020 o 0:00 Nick Desaulniers <ndesaulniers@...gle.com> napísal(a):
> >
> > On Tue, Aug 18, 2020 at 2:41 PM Arvind Sankar <nivedita@...m.mit.edu> wrote:
> > >
> > > Note that -fno-builtin-foo seems to mean slightly different things in
> > > clang and gcc. From experimentation, clang will neither optimize a call
> > > to foo, nor perform an optimization that introduces a call to foo. gcc
> > > will avoid optimizing calls to foo, but it can still generate new calls
> > > to foo while optimizing something else. Which means that
> > > -fno-builtin-{bcmp,stpcpy} only solves things for clang, not gcc. It's
> > > just that gcc doesn't seem to have implemented those optimizations.
> >
> > Can you please share some godbolt links that demonstrate these observations?
> Here:
> https://godbolt.org/z/qjo5P6

Ok, when I implemented this version that used -fno-builtin-stpcpy, I
initially+locally had it added to CLANG_FLAGS rather than
KBUILD_CFLAGS, but changed it to KBUILD_CFLAGS because I believed that
BOTH compilers would not lower calls to foo given -fno-builtin-foo.
Since we have evidence that's not the case, maybe that's the final
solution and my final proposal (v3). A summary:

1. v1 "implement stpcpy"
https://lore.kernel.org/lkml/20200815002417.1512973-1-ndesaulniers@google.com/T/#u
"Please don't provide more unsafe string functions to the kernel"
2. v2 "KBUILD_CFLAGS += -fno-builtin-stpcpy"
https://lore.kernel.org/lkml/20200817220212.338670-1-ndesaulniers@google.com/T/#t
"-fno-builtin-* doesn't work like that on GCC"
3. v3 "CLANG_FLAGS += -fno-builtin-stpcpy" TODO

I'll argue that providing an implementation of stpcpy while hiding the
declaration from include/lib/string.h "for the possibility that GCC
may one day perform the same libcall optimization" as YAGNI, that we
may cross that bridge by resurrecting v1 (with the removal of the hunk
against include/lib/string.h).  This also defers adding more unsafe
string functions in the kernel.

Thoughts before I send the patch and write that up?
-- 
Thanks,
~Nick Desaulniers