From: "Arnd Bergmann" <arnd@arndb.de>
To: "Kees Cook" <keescook@chromium.org>, "Arnd Bergmann" <arnd@kernel.org>
Cc: kasan-dev@googlegroups.com,
"Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
"Alexander Potapenko" <glider@google.com>,
"Andrey Konovalov" <andreyknvl@gmail.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
"Marco Elver" <elver@google.com>,
linux-media@vger.kernel.org, linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Dan Carpenter" <dan.carpenter@linaro.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Tom Rix" <trix@redhat.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH] [RFC] ubsan: disallow bounds checking with gcov on broken gcc
Date: Thu, 01 Jun 2023 19:50:38 +0200 [thread overview]
Message-ID: <f6fcae8a-9b50-48e4-84e9-c37613226c63@app.fastmail.com> (raw)
In-Reply-To: <202306010909.89C4BED@keescook>
On Thu, Jun 1, 2023, at 18:14, Kees Cook wrote:
> On Thu, Jun 01, 2023 at 05:18:11PM +0200, Arnd Bergmann wrote:
>
> I think more production systems will have CONFIG_UBSAN_BOUNDS enabled
> (e.g. Ubuntu has had it enabled for more than a year now) than GCOV,
> so I'd prefer we maintain all*config coverage for the more commonly
> used config.
Fair enough, I can send that as v2, but let's see what the others
think first.
>> config CC_HAS_UBSAN_BOUNDS_STRICT
>> def_bool $(cc-option,-fsanitize=bounds-strict)
>> + # work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074
>> + depends on GCC_VERSION > 140000 || !GCOV_PROFILE_ALL
>> help
>> The -fsanitize=bounds-strict option is only available on GCC,
>> but uses the more strict handling of arrays that includes knowledge
>
> Alternatively, how about falling back to -fsanitize=bounds instead, as
> that (which has less coverage) wasn't triggering the stack frame
> warnings?
>
> i.e. fall back through these:
> -fsanitize=array-bounds (Clang)
> -fsanitize=bounds-strict (!GCOV || bug fixed in GCC)
> -fsanitize=bounds
From what I can tell, -fsanitize=bounds has the same problem
as -fsanitize=bounds-strict, so that would not help.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Kees Cook" <keescook@chromium.org>, "Arnd Bergmann" <arnd@kernel.org>
Cc: kasan-dev@googlegroups.com,
"Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
"Alexander Potapenko" <glider@google.com>,
"Andrey Konovalov" <andreyknvl@gmail.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
"Marco Elver" <elver@google.com>,
linux-media@vger.kernel.org, linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Dan Carpenter" <dan.carpenter@linaro.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Tom Rix" <trix@redhat.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH] [RFC] ubsan: disallow bounds checking with gcov on broken gcc
Date: Thu, 01 Jun 2023 19:50:38 +0200 [thread overview]
Message-ID: <f6fcae8a-9b50-48e4-84e9-c37613226c63@app.fastmail.com> (raw)
In-Reply-To: <202306010909.89C4BED@keescook>
On Thu, Jun 1, 2023, at 18:14, Kees Cook wrote:
> On Thu, Jun 01, 2023 at 05:18:11PM +0200, Arnd Bergmann wrote:
>
> I think more production systems will have CONFIG_UBSAN_BOUNDS enabled
> (e.g. Ubuntu has had it enabled for more than a year now) than GCOV,
> so I'd prefer we maintain all*config coverage for the more commonly
> used config.
Fair enough, I can send that as v2, but let's see what the others
think first.
>> config CC_HAS_UBSAN_BOUNDS_STRICT
>> def_bool $(cc-option,-fsanitize=bounds-strict)
>> + # work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074
>> + depends on GCC_VERSION > 140000 || !GCOV_PROFILE_ALL
>> help
>> The -fsanitize=bounds-strict option is only available on GCC,
>> but uses the more strict handling of arrays that includes knowledge
>
> Alternatively, how about falling back to -fsanitize=bounds instead, as
> that (which has less coverage) wasn't triggering the stack frame
> warnings?
>
> i.e. fall back through these:
> -fsanitize=array-bounds (Clang)
> -fsanitize=bounds-strict (!GCOV || bug fixed in GCC)
> -fsanitize=bounds
From what I can tell, -fsanitize=bounds has the same problem
as -fsanitize=bounds-strict, so that would not help.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-06-01 17:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 15:18 [PATCH] [RFC] ubsan: disallow bounds checking with gcov on broken gcc Arnd Bergmann
2023-06-01 15:18 ` Arnd Bergmann
2023-06-01 16:14 ` Kees Cook
2023-06-01 16:14 ` Kees Cook
2023-06-01 17:50 ` Arnd Bergmann [this message]
2023-06-01 17:50 ` Arnd Bergmann
2023-06-01 18:28 ` Kees Cook
2023-06-01 18:28 ` Kees Cook
2023-06-01 19:03 ` Arnd Bergmann
2023-06-01 19:03 ` Arnd Bergmann
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=f6fcae8a-9b50-48e4-84e9-c37613226c63@app.fastmail.com \
--to=arnd@arndb.de \
--cc=andreyknvl@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ardb@kernel.org \
--cc=arnd@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=jpoimboe@kernel.org \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ryabinin.a.a@gmail.com \
--cc=trix@redhat.com \
--cc=vincenzo.frascino@arm.com \
/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.