From: Kees Cook <keescook@chromium.org>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Nick Desaulniers <ndesaulniers@google.com>,
Marco Elver <elver@google.com>,
Randy Dunlap <rdunlap@infradead.org>,
Dmitry Vyukov <dvyukov@google.com>,
George Popescu <georgepope@android.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
clang-built-linux@googlegroups.com, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] ubsan: Move cc-option tests into Kconfig
Date: Mon, 5 Oct 2020 23:01:44 -0700 [thread overview]
Message-ID: <202010052258.96765BC83@keescook> (raw)
In-Reply-To: <20201004070847.GA1650@Ryzen-9-3900X.localdomain>
On Sun, Oct 04, 2020 at 12:08:47AM -0700, Nathan Chancellor wrote:
> On Fri, Oct 02, 2020 at 03:15:24PM -0700, Kees Cook wrote:
> > Instead of doing if/endif blocks with cc-option calls in the UBSAN
> > Makefile, move all the tests into Kconfig and use the Makefile to
> > collect the results.
> >
> > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/
>
> I tested menuconfig to make sure all the flags when CONFIG_UBSAN_MISC is
> flipped.
>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Awesome, thank you!
> One comment below.
>
> > [...]
> > diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> > index 9716dab06bc7..72862da47baf 100644
> > --- a/scripts/Makefile.ubsan
> > +++ b/scripts/Makefile.ubsan
> > @@ -1,37 +1,21 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > -export CFLAGS_UBSAN :=
> > +# -fsanitize=* options makes GCC less smart than usual and
> > +# increases the number of 'maybe-uninitialized' false-positives.
> > +ubsan-cflags-$(CONFIG_UBSAN) += $(call cc-disable-warning, maybe-uninitialized)
>
> Is this just to force -Wno-maybe-uninitialized even when W=2?
> -Wmaybe-uninitialized is already disabled globally after
> commit 78a5255ffb6a ("Stop the ad-hoc games with
> -Wno-maybe-initialized"). I feel like it might be worth a comment in
> case that changes in the future but maybe that is a bit much.
>
> > [...]
> > - # -fsanitize=* options makes GCC less smart than usual and
> > - # increase number of 'maybe-uninitialized false-positives
> > - CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized)
It's just a direct copying of the existing logic, but into the new
"ubsan-cflags-y" style. But yes, AFAICT, that was the intent when it was
added in commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized
warning for "make W=1"").
So for this patch, I kept the logic as it was.
--
Kees Cook
next prev parent reply other threads:[~2020-10-06 6:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 22:15 [PATCH 0/4] Clean up UBSAN Makefile Kees Cook
2020-10-02 22:15 ` [PATCH 1/4] ubsan: Move cc-option tests into Kconfig Kees Cook
2020-10-04 7:08 ` Nathan Chancellor
2020-10-06 6:01 ` Kees Cook [this message]
2020-10-02 22:15 ` [PATCH 2/4] ubsan: Disable object-size sanitizer under GCC Kees Cook
2020-10-04 7:10 ` Nathan Chancellor
2020-10-02 22:15 ` [PATCH 3/4] ubsan: Force -Wno-maybe-uninitialized only for GCC Kees Cook
2020-10-04 7:16 ` Nathan Chancellor
2020-10-06 6:03 ` Kees Cook
2020-10-02 22:15 ` [PATCH 4/4] ubsan: Disable UBSAN_TRAP for all*config Kees Cook
2020-10-04 7:16 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202010052258.96765BC83@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=clang-built-linux@googlegroups.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=georgepope@android.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=oberpar@linux.ibm.com \
--cc=rdunlap@infradead.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.