* [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
@ 2023-04-05 2:23 Kees Cook
2023-04-07 22:00 ` Nick Desaulniers
2023-06-21 16:42 ` Guenter Roeck
0 siblings, 2 replies; 6+ messages in thread
From: Kees Cook @ 2023-04-05 2:23 UTC (permalink / raw)
To: Marco Elver
Cc: Kees Cook, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers,
Nicolas Schier, Tom Rix, Josh Poimboeuf, Miroslav Benes,
linux-kbuild, llvm, Sudip Mukherjee, Lukas Bulwahn, linux-kernel,
linux-hardening
The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
match Clang's stricter behavior.
Cc: Marco Elver <elver@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Nicolas Schier <nicolas@fjasle.eu>
Cc: Tom Rix <trix@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Cc: llvm@lists.linux.dev
Signed-off-by: Kees Cook <keescook@chromium.org>
---
v2: improve help text (nathan)
v1: https://lore.kernel.org/lkml/20230302225444.never.053-kees@kernel.org/
---
lib/Kconfig.ubsan | 56 +++++++++++++++++++++++-------------------
scripts/Makefile.ubsan | 2 +-
2 files changed, 32 insertions(+), 26 deletions(-)
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index fd15230a703b..65d8bbcba438 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -27,16 +27,29 @@ config UBSAN_TRAP
the system. For some system builders this is an acceptable
trade-off.
-config CC_HAS_UBSAN_BOUNDS
- def_bool $(cc-option,-fsanitize=bounds)
+config CC_HAS_UBSAN_BOUNDS_STRICT
+ def_bool $(cc-option,-fsanitize=bounds-strict)
+ help
+ The -fsanitize=bounds-strict option is only available on GCC,
+ but uses the more strict handling of arrays that includes knowledge
+ of flexible arrays, which is comparable to Clang's regular
+ -fsanitize=bounds.
config CC_HAS_UBSAN_ARRAY_BOUNDS
def_bool $(cc-option,-fsanitize=array-bounds)
+ help
+ Under Clang, the -fsanitize=bounds option is actually composed
+ of two more specific options, -fsanitize=array-bounds and
+ -fsanitize=local-bounds. However, -fsanitize=local-bounds can
+ only be used when trap mode is enabled. (See also the help for
+ CONFIG_LOCAL_BOUNDS.) Explicitly check for -fsanitize=array-bounds
+ so that we can build up the options needed for UBSAN_BOUNDS
+ with or without UBSAN_TRAP.
config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
- depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
+ depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS_STRICT
help
This option enables detection of directly indexed out of bounds
array accesses, where the array size is known at compile time.
@@ -44,33 +57,26 @@ config UBSAN_BOUNDS
to the {str,mem}*cpy() family of functions (that is addressed
by CONFIG_FORTIFY_SOURCE).
-config UBSAN_ONLY_BOUNDS
- def_bool CC_HAS_UBSAN_BOUNDS && !CC_HAS_UBSAN_ARRAY_BOUNDS
- depends on UBSAN_BOUNDS
+config UBSAN_BOUNDS_STRICT
+ def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_BOUNDS_STRICT
help
- This is a weird case: Clang's -fsanitize=bounds includes
- -fsanitize=local-bounds, but it's trapping-only, so for
- Clang, we must use -fsanitize=array-bounds when we want
- traditional array bounds checking enabled. For GCC, we
- want -fsanitize=bounds.
+ GCC's bounds sanitizer. This option is used to select the
+ correct options in Makefile.ubsan.
config UBSAN_ARRAY_BOUNDS
- def_bool CC_HAS_UBSAN_ARRAY_BOUNDS
- depends on UBSAN_BOUNDS
+ def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_ARRAY_BOUNDS
+ help
+ Clang's array bounds sanitizer. This option is used to select
+ the correct options in Makefile.ubsan.
config UBSAN_LOCAL_BOUNDS
- bool "Perform array local bounds checking"
- depends on UBSAN_TRAP
- depends on $(cc-option,-fsanitize=local-bounds)
- help
- This option enables -fsanitize=local-bounds which traps when an
- exception/error is detected. Therefore, it may only be enabled
- with CONFIG_UBSAN_TRAP.
-
- Enabling this option detects errors due to accesses through a
- pointer that is derived from an object of a statically-known size,
- where an added offset (which may not be known statically) is
- out-of-bounds.
+ def_bool UBSAN_ARRAY_BOUNDS && UBSAN_TRAP
+ help
+ This option enables Clang's -fsanitize=local-bounds which traps
+ when an access through a pointer that is derived from an object
+ of a statically-known size, where an added offset (which may not
+ be known statically) is out-of-bounds. Since this option is
+ trap-only, it depends on CONFIG_UBSAN_TRAP.
config UBSAN_SHIFT
bool "Perform checking for bit-shift overflows"
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 7099c603ff0a..4749865c1b2c 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -2,7 +2,7 @@
# Enable available and selected UBSAN features.
ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment
-ubsan-cflags-$(CONFIG_UBSAN_ONLY_BOUNDS) += -fsanitize=bounds
+ubsan-cflags-$(CONFIG_UBSAN_BOUNDS_STRICT) += -fsanitize=bounds-strict
ubsan-cflags-$(CONFIG_UBSAN_ARRAY_BOUNDS) += -fsanitize=array-bounds
ubsan-cflags-$(CONFIG_UBSAN_LOCAL_BOUNDS) += -fsanitize=local-bounds
ubsan-cflags-$(CONFIG_UBSAN_SHIFT) += -fsanitize=shift
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
2023-04-05 2:23 [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC Kees Cook
@ 2023-04-07 22:00 ` Nick Desaulniers
2023-06-21 16:42 ` Guenter Roeck
1 sibling, 0 replies; 6+ messages in thread
From: Nick Desaulniers @ 2023-04-07 22:00 UTC (permalink / raw)
To: Kees Cook
Cc: Marco Elver, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Tom Rix, Josh Poimboeuf, Miroslav Benes, linux-kbuild, llvm,
Sudip Mukherjee, Lukas Bulwahn, linux-kernel, linux-hardening
On Tue, Apr 4, 2023 at 7:24 PM Kees Cook <keescook@chromium.org> wrote:
>
> The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
> leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
> match Clang's stricter behavior.
>
> Cc: Marco Elver <elver@google.com>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Nicolas Schier <nicolas@fjasle.eu>
> Cc: Tom Rix <trix@redhat.com>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: Miroslav Benes <mbenes@suse.cz>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> v2: improve help text (nathan)
> v1: https://lore.kernel.org/lkml/20230302225444.never.053-kees@kernel.org/
> ---
> lib/Kconfig.ubsan | 56 +++++++++++++++++++++++-------------------
> scripts/Makefile.ubsan | 2 +-
> 2 files changed, 32 insertions(+), 26 deletions(-)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index fd15230a703b..65d8bbcba438 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -27,16 +27,29 @@ config UBSAN_TRAP
> the system. For some system builders this is an acceptable
> trade-off.
>
> -config CC_HAS_UBSAN_BOUNDS
> - def_bool $(cc-option,-fsanitize=bounds)
> +config CC_HAS_UBSAN_BOUNDS_STRICT
> + def_bool $(cc-option,-fsanitize=bounds-strict)
> + help
> + The -fsanitize=bounds-strict option is only available on GCC,
> + but uses the more strict handling of arrays that includes knowledge
> + of flexible arrays, which is comparable to Clang's regular
> + -fsanitize=bounds.
>
> config CC_HAS_UBSAN_ARRAY_BOUNDS
> def_bool $(cc-option,-fsanitize=array-bounds)
> + help
> + Under Clang, the -fsanitize=bounds option is actually composed
> + of two more specific options, -fsanitize=array-bounds and
Heh, that was literally the latest blog post I was working on...2
weeks ago? WIP.
Would it make sense to use CC_IS_CLANG (as in lib/Kconfig.k{a|c}san)
and CC_IS_GCC in addition to the cc-option tests, since the help texts
make it clear there's compiler specific differences here?
I've also sent
https://lore.kernel.org/llvm/20230407215406.768464-1-ndesaulniers@google.com/
while looking at this patch. Maybe more cc-option tests are no longer
necessary at this point, but I haven't checked the rest.
> + -fsanitize=local-bounds. However, -fsanitize=local-bounds can
> + only be used when trap mode is enabled. (See also the help for
> + CONFIG_LOCAL_BOUNDS.) Explicitly check for -fsanitize=array-bounds
> + so that we can build up the options needed for UBSAN_BOUNDS
> + with or without UBSAN_TRAP.
>
> config UBSAN_BOUNDS
> bool "Perform array index bounds checking"
> default UBSAN
> - depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
> + depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS_STRICT
> help
> This option enables detection of directly indexed out of bounds
> array accesses, where the array size is known at compile time.
> @@ -44,33 +57,26 @@ config UBSAN_BOUNDS
> to the {str,mem}*cpy() family of functions (that is addressed
> by CONFIG_FORTIFY_SOURCE).
>
> -config UBSAN_ONLY_BOUNDS
> - def_bool CC_HAS_UBSAN_BOUNDS && !CC_HAS_UBSAN_ARRAY_BOUNDS
> - depends on UBSAN_BOUNDS
> +config UBSAN_BOUNDS_STRICT
> + def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_BOUNDS_STRICT
> help
> - This is a weird case: Clang's -fsanitize=bounds includes
> - -fsanitize=local-bounds, but it's trapping-only, so for
> - Clang, we must use -fsanitize=array-bounds when we want
> - traditional array bounds checking enabled. For GCC, we
> - want -fsanitize=bounds.
> + GCC's bounds sanitizer. This option is used to select the
> + correct options in Makefile.ubsan.
>
> config UBSAN_ARRAY_BOUNDS
> - def_bool CC_HAS_UBSAN_ARRAY_BOUNDS
> - depends on UBSAN_BOUNDS
> + def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_ARRAY_BOUNDS
> + help
> + Clang's array bounds sanitizer. This option is used to select
> + the correct options in Makefile.ubsan.
>
> config UBSAN_LOCAL_BOUNDS
> - bool "Perform array local bounds checking"
> - depends on UBSAN_TRAP
> - depends on $(cc-option,-fsanitize=local-bounds)
> - help
> - This option enables -fsanitize=local-bounds which traps when an
> - exception/error is detected. Therefore, it may only be enabled
> - with CONFIG_UBSAN_TRAP.
> -
> - Enabling this option detects errors due to accesses through a
> - pointer that is derived from an object of a statically-known size,
> - where an added offset (which may not be known statically) is
> - out-of-bounds.
> + def_bool UBSAN_ARRAY_BOUNDS && UBSAN_TRAP
> + help
> + This option enables Clang's -fsanitize=local-bounds which traps
> + when an access through a pointer that is derived from an object
> + of a statically-known size, where an added offset (which may not
> + be known statically) is out-of-bounds. Since this option is
> + trap-only, it depends on CONFIG_UBSAN_TRAP.
>
> config UBSAN_SHIFT
> bool "Perform checking for bit-shift overflows"
> diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> index 7099c603ff0a..4749865c1b2c 100644
> --- a/scripts/Makefile.ubsan
> +++ b/scripts/Makefile.ubsan
> @@ -2,7 +2,7 @@
>
> # Enable available and selected UBSAN features.
> ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment
> -ubsan-cflags-$(CONFIG_UBSAN_ONLY_BOUNDS) += -fsanitize=bounds
> +ubsan-cflags-$(CONFIG_UBSAN_BOUNDS_STRICT) += -fsanitize=bounds-strict
> ubsan-cflags-$(CONFIG_UBSAN_ARRAY_BOUNDS) += -fsanitize=array-bounds
> ubsan-cflags-$(CONFIG_UBSAN_LOCAL_BOUNDS) += -fsanitize=local-bounds
> ubsan-cflags-$(CONFIG_UBSAN_SHIFT) += -fsanitize=shift
> --
> 2.34.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
2023-04-05 2:23 [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC Kees Cook
2023-04-07 22:00 ` Nick Desaulniers
@ 2023-06-21 16:42 ` Guenter Roeck
2023-06-21 17:52 ` Kees Cook
1 sibling, 1 reply; 6+ messages in thread
From: Guenter Roeck @ 2023-06-21 16:42 UTC (permalink / raw)
To: Kees Cook
Cc: Marco Elver, Masahiro Yamada, Nathan Chancellor,
Nick Desaulniers, Nicolas Schier, Tom Rix, Josh Poimboeuf,
Miroslav Benes, linux-kbuild, llvm, Sudip Mukherjee,
Lukas Bulwahn, linux-kernel, linux-hardening
Hi,
On Tue, Apr 04, 2023 at 07:23:59PM -0700, Kees Cook wrote:
> The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
> leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
> match Clang's stricter behavior.
>
> Cc: Marco Elver <elver@google.com>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Nicolas Schier <nicolas@fjasle.eu>
> Cc: Tom Rix <trix@redhat.com>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: Miroslav Benes <mbenes@suse.cz>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
This patch, presumably as side effect, enables CONFIG_ARCH_STM32
for arm64:allmodconfig. As consequence, CONFIG_STM32_RPROC is enabled
as well. This in turn results in the following build error.
Building arm64:allmodconfig ... failed
--------------
Error log:
In file included from include/linux/printk.h:564,
from include/asm-generic/bug.h:22,
from arch/arm64/include/asm/bug.h:26,
from include/linux/bug.h:5,
from include/linux/fortify-string.h:5,
from include/linux/string.h:254,
from include/linux/dma-mapping.h:7,
from drivers/remoteproc/stm32_rproc.c:9:
drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':
drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t'
I did not try to understand what is going on, but reverting this
patch fixes the problem.
---
bisect script:
rm .config
make-arm64 mrproper
make-arm64 -j allmodconfig
if ! grep -q CONFIG_ARCH_STM32 .config; then
exit 1
fi
exit 0
---
bisect log:
# bad: [15e71592dbae49a674429c618a10401d7f992ac3] Add linux-next specific files for 20230621
# good: [45a3e24f65e90a047bef86f927ebdc4c710edaa1] Linux 6.4-rc7
git bisect start 'HEAD' 'v6.4-rc7'
# good: [e867e67cd55ae460c860ffd896c7fc96add2821c] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
git bisect good e867e67cd55ae460c860ffd896c7fc96add2821c
# good: [0ab4015a11182e2a19c3dd52db85418f370cef39] Merge branch 'for-next' of git://git.kernel.dk/linux-block.git
git bisect good 0ab4015a11182e2a19c3dd52db85418f370cef39
# good: [50b29407850776d7c61461f883e5896dcea596a4] Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
git bisect good 50b29407850776d7c61461f883e5896dcea596a4
# good: [04d46f23e86112fc9d6469fc0155ce19faabc181] Merge branch 'staging-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git bisect good 04d46f23e86112fc9d6469fc0155ce19faabc181
# good: [bdd44289ba061dab3863ff80a5999d4c6160b93d] Merge branch 'gpio/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
git bisect good bdd44289ba061dab3863ff80a5999d4c6160b93d
# good: [c7d13e64a19b0bbed1a6eb18e9b4fd55f7530e5d] Merge branch 'at24/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
git bisect good c7d13e64a19b0bbed1a6eb18e9b4fd55f7530e5d
# good: [6477d1cebd3339658f8421e05380576ed535677c] Merge branch 'rust-next' of https://github.com/Rust-for-Linux/linux.git
git bisect good 6477d1cebd3339658f8421e05380576ed535677c
# bad: [d01a77afd6bef1b3a2ed15e8ca6887ca7da0cddc] lib/string_helpers: Change returned value of the strreplace()
git bisect bad d01a77afd6bef1b3a2ed15e8ca6887ca7da0cddc
# bad: [d67790ddf0219aa0ad3e13b53ae0a7619b3425a2] overflow: Add struct_size_t() helper
git bisect bad d67790ddf0219aa0ad3e13b53ae0a7619b3425a2
# bad: [30ad0627f169f56180e668e7223eaa43aa190a75] dlm: Replace all non-returning strlcpy with strscpy
git bisect bad 30ad0627f169f56180e668e7223eaa43aa190a75
# bad: [3bf301e1ab85e18ed0e337ce124dc71d6d7b5fd7] string: Add Kunit tests for strcat() family
git bisect bad 3bf301e1ab85e18ed0e337ce124dc71d6d7b5fd7
# bad: [ead62aa370a81c4fb42a44c4edeafe13e0a3a703] fortify: strscpy: Fix flipped q and p docstring typo
git bisect bad ead62aa370a81c4fb42a44c4edeafe13e0a3a703
# bad: [2d47c6956ab3c8b580a59d7704aab3e2a4882b6c] ubsan: Tighten UBSAN_BOUNDS on GCC
git bisect bad 2d47c6956ab3c8b580a59d7704aab3e2a4882b6c
# first bad commit: [2d47c6956ab3c8b580a59d7704aab3e2a4882b6c] ubsan: Tighten UBSAN_BOUNDS on GCC
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
2023-06-21 16:42 ` Guenter Roeck
@ 2023-06-21 17:52 ` Kees Cook
2023-06-22 0:50 ` Guenter Roeck
0 siblings, 1 reply; 6+ messages in thread
From: Kees Cook @ 2023-06-21 17:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Marco Elver, Masahiro Yamada, Nathan Chancellor,
Nick Desaulniers, Nicolas Schier, Tom Rix, Josh Poimboeuf,
Miroslav Benes, linux-kbuild, llvm, Sudip Mukherjee,
Lukas Bulwahn, linux-kernel, linux-hardening
On Wed, Jun 21, 2023 at 09:42:01AM -0700, Guenter Roeck wrote:
> Hi,
>
> On Tue, Apr 04, 2023 at 07:23:59PM -0700, Kees Cook wrote:
> > The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
> > leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
> > match Clang's stricter behavior.
> >
> > Cc: Marco Elver <elver@google.com>
> > Cc: Masahiro Yamada <masahiroy@kernel.org>
> > Cc: Nathan Chancellor <nathan@kernel.org>
> > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > Cc: Nicolas Schier <nicolas@fjasle.eu>
> > Cc: Tom Rix <trix@redhat.com>
> > Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> > Cc: Miroslav Benes <mbenes@suse.cz>
> > Cc: linux-kbuild@vger.kernel.org
> > Cc: llvm@lists.linux.dev
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
>
> This patch, presumably as side effect, enables CONFIG_ARCH_STM32
> for arm64:allmodconfig. As consequence, CONFIG_STM32_RPROC is enabled
> as well. This in turn results in the following build error.
>
> Building arm64:allmodconfig ... failed
> --------------
> Error log:
> In file included from include/linux/printk.h:564,
> from include/asm-generic/bug.h:22,
> from arch/arm64/include/asm/bug.h:26,
> from include/linux/bug.h:5,
> from include/linux/fortify-string.h:5,
> from include/linux/string.h:254,
> from include/linux/dma-mapping.h:7,
> from drivers/remoteproc/stm32_rproc.c:9:
> drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':
> drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t'
>
> I did not try to understand what is going on, but reverting this
> patch fixes the problem.
Well that is really weird! I will investigate... this patch should be
pretty self-contained...
--
Kees Cook
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
2023-06-21 17:52 ` Kees Cook
@ 2023-06-22 0:50 ` Guenter Roeck
2023-06-22 3:11 ` Kees Cook
0 siblings, 1 reply; 6+ messages in thread
From: Guenter Roeck @ 2023-06-22 0:50 UTC (permalink / raw)
To: Kees Cook
Cc: Marco Elver, Masahiro Yamada, Nathan Chancellor,
Nick Desaulniers, Nicolas Schier, Tom Rix, Josh Poimboeuf,
Miroslav Benes, linux-kbuild, llvm, Sudip Mukherjee,
Lukas Bulwahn, linux-kernel, linux-hardening
On 6/21/23 10:52, Kees Cook wrote:
> On Wed, Jun 21, 2023 at 09:42:01AM -0700, Guenter Roeck wrote:
>> Hi,
>>
>> On Tue, Apr 04, 2023 at 07:23:59PM -0700, Kees Cook wrote:
>>> The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
>>> leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
>>> match Clang's stricter behavior.
>>>
>>> Cc: Marco Elver <elver@google.com>
>>> Cc: Masahiro Yamada <masahiroy@kernel.org>
>>> Cc: Nathan Chancellor <nathan@kernel.org>
>>> Cc: Nick Desaulniers <ndesaulniers@google.com>
>>> Cc: Nicolas Schier <nicolas@fjasle.eu>
>>> Cc: Tom Rix <trix@redhat.com>
>>> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
>>> Cc: Miroslav Benes <mbenes@suse.cz>
>>> Cc: linux-kbuild@vger.kernel.org
>>> Cc: llvm@lists.linux.dev
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>
>> This patch, presumably as side effect, enables CONFIG_ARCH_STM32
>> for arm64:allmodconfig. As consequence, CONFIG_STM32_RPROC is enabled
>> as well. This in turn results in the following build error.
>>
>> Building arm64:allmodconfig ... failed
>> --------------
>> Error log:
>> In file included from include/linux/printk.h:564,
>> from include/asm-generic/bug.h:22,
>> from arch/arm64/include/asm/bug.h:26,
>> from include/linux/bug.h:5,
>> from include/linux/fortify-string.h:5,
>> from include/linux/string.h:254,
>> from include/linux/dma-mapping.h:7,
>> from drivers/remoteproc/stm32_rproc.c:9:
>> drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':
>> drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t'
>>
>> I did not try to understand what is going on, but reverting this
>> patch fixes the problem.
>
> Well that is really weird! I will investigate... this patch should be
> pretty self-contained...
>
Meh, it is. Sorry for the noise. My bisect script was wrong.
Guenter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC
2023-06-22 0:50 ` Guenter Roeck
@ 2023-06-22 3:11 ` Kees Cook
0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2023-06-22 3:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: Marco Elver, Masahiro Yamada, Nathan Chancellor,
Nick Desaulniers, Nicolas Schier, Tom Rix, Josh Poimboeuf,
Miroslav Benes, linux-kbuild, llvm, Sudip Mukherjee,
Lukas Bulwahn, linux-kernel, linux-hardening
On Wed, Jun 21, 2023 at 05:50:53PM -0700, Guenter Roeck wrote:
> On 6/21/23 10:52, Kees Cook wrote:
> > On Wed, Jun 21, 2023 at 09:42:01AM -0700, Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Tue, Apr 04, 2023 at 07:23:59PM -0700, Kees Cook wrote:
> > > > The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
> > > > leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
> > > > match Clang's stricter behavior.
> > > >
> > > > Cc: Marco Elver <elver@google.com>
> > > > Cc: Masahiro Yamada <masahiroy@kernel.org>
> > > > Cc: Nathan Chancellor <nathan@kernel.org>
> > > > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > > > Cc: Nicolas Schier <nicolas@fjasle.eu>
> > > > Cc: Tom Rix <trix@redhat.com>
> > > > Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> > > > Cc: Miroslav Benes <mbenes@suse.cz>
> > > > Cc: linux-kbuild@vger.kernel.org
> > > > Cc: llvm@lists.linux.dev
> > > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > ---
> > >
> > > This patch, presumably as side effect, enables CONFIG_ARCH_STM32
> > > for arm64:allmodconfig. As consequence, CONFIG_STM32_RPROC is enabled
> > > as well. This in turn results in the following build error.
> > >
> > > Building arm64:allmodconfig ... failed
> > > --------------
> > > Error log:
> > > In file included from include/linux/printk.h:564,
> > > from include/asm-generic/bug.h:22,
> > > from arch/arm64/include/asm/bug.h:26,
> > > from include/linux/bug.h:5,
> > > from include/linux/fortify-string.h:5,
> > > from include/linux/string.h:254,
> > > from include/linux/dma-mapping.h:7,
> > > from drivers/remoteproc/stm32_rproc.c:9:
> > > drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':
> > > drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t'
> > >
> > > I did not try to understand what is going on, but reverting this
> > > patch fixes the problem.
> >
> > Well that is really weird! I will investigate... this patch should be
> > pretty self-contained...
> >
> Meh, it is. Sorry for the noise. My bisect script was wrong.
Oh, okay; whew! I was really scratching my head. :)
--
Kees Cook
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-06-22 3:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-05 2:23 [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC Kees Cook
2023-04-07 22:00 ` Nick Desaulniers
2023-06-21 16:42 ` Guenter Roeck
2023-06-21 17:52 ` Kees Cook
2023-06-22 0:50 ` Guenter Roeck
2023-06-22 3:11 ` Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).