lib/ubsan: default UBSAN_ALIGNMENT to not set
Subsystems (2)
PATCH 1/1 lib/ubsan: default UBSAN_ALIGNMENT to not set
When booting an allmodconfig kernel, there are a lot of false-positives. With a message like this 'UBSAN: Undefined behaviour in...' with a call trace that follows.
Reworked so that when building a allmodconfig kernel that turns everything into '=m' or '=y' will turn off UBSAN_ALIGNMENT.
--- lib/Kconfig.ubsan | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
lib/Kconfig.ubsan +9 -5
@@ -27,15 +27,19 @@ config UBSAN_SANITIZE_ALL Enabling this option will get kernel image size increased significantly. -config UBSAN_ALIGNMENT - bool "Enable checking of pointers alignment" +config UBSAN_NO_ALIGNMENT + bool "Disable checking of pointers alignment" depends on UBSAN - default y if !HAVE_EFFICIENT_UNALIGNED_ACCESS + default y if HAVE_EFFICIENT_UNALIGNED_ACCESS help - This option enables detection of unaligned memory accesses. - Enabling this option on architectures that support unaligned + This option disables the check of unaligned memory accesses. + This option should be used when building allmodconfig. + Disabling this option on architectures that support unaligned accesses may produce a lot of false positives. +config UBSAN_ALIGNMENT + def_bool !UBSAN_NO_ALIGNMENT + config TEST_UBSAN tristate "Module for testing for undefined behavior detection" depends on m && UBSAN
Signature · 1 line
2.19.2
Quoted 10 lines · Anders Roxell
When booting an allmodconfig kernel, there are a lot of false-positives. With a message like this 'UBSAN: Undefined behaviour in...' with a call trace that follows.
Reworked so that when building a allmodconfig kernel that turns everything into '=m' or '=y' will turn off
UBSAN_ALIGNMENT.Suggested-by Arnd Bergmann <[email protected]>Signed-off-by Anders Roxell <[email protected]>---
Quoted 33 lines
lib/Kconfig.ubsan | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)lib/Kconfig.ubsan +9
-5@@ -27,15 +27,19 @@ config UBSAN_SANITIZE_ALL Enabling this option will get kernel image size increased significantly. -config UBSAN_ALIGNMENT - bool "Enable checking of pointers alignment" +config UBSAN_NO_ALIGNMENT + bool "Disable checking of pointers alignment" depends on UBSAN - default y if !HAVE_EFFICIENT_UNALIGNED_ACCESS + default y if HAVE_EFFICIENT_UNALIGNED_ACCESS help - This option enables detection of unaligned memory accesses. - Enabling this option on architectures that support unaligned + This option disables the check of unaligned memory accesses. + This option should be used when building allmodconfig. + Disabling this option on architectures that support unaligned accesses may produce a lot of false positives. +config UBSAN_ALIGNMENT + def_bool !UBSAN_NO_ALIGNMENT + config TEST_UBSAN tristate "Module for testing for undefined behavior detection" depends on m && UBSAN
Andrew Morton
maintainerQuoted 7 lines · On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]>…
Quoted 4 lines · Anders Roxell
When booting an allmodconfig kernel, there are a lot of false-positives. With a message like this 'UBSAN: Undefined behaviour in...' with a call trace that follows.
Quoted 9 lines
Quoted 6 lines
Reworked so that when building a allmodconfig kernel that turns everything into '=m' or '=y' will turn off
UBSAN_ALIGNMENT.Suggested-by Arnd Bergmann <[email protected]>Signed-off-by Anders Roxell <[email protected]>---
Acked-by Andrey Ryabinin <[email protected]>
Confused. Why does allmodconfig result in UBSAN warnings?
Quoted 12 lines · Andrew Morton
Quoted 10 lines · On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]>…
Quoted 7 lines · Anders Roxell
When booting an allmodconfig kernel, there are a lot of false-positives. With a message like this 'UBSAN: Undefined behaviour in...' with a call trace that follows.
Reworked so that when building a allmodconfig kernel that turns everything into '=m' or '=y' will turn off
UBSAN_ALIGNMENT.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Suggested-by Arnd Bergmann <[email protected]>Signed-off-by Anders Roxell <[email protected]>---
Acked-by Andrey Ryabinin <[email protected]>Confused. Why does allmodconfig result in UBSAN warnings?
UBSAN warnings is a result of enabling noisy CONFIG_UBSAN_ALIGNMENT which is disabled
by default if HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
It's noisy even if don't have efficient unaligned access, e.g. people often add __cacheline_aligned_in_smp in structs, but forget to align allocations of such struct (kmalloc() give 8-byte alignment in worst case).
Quoted 17 lines · Andrey Ryabinin
Quoted 16 lines · Andrew Morton
Quoted 14 lines · On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]>…
Quoted 10 lines · Anders Roxell
When booting an allmodconfig kernel, there are a lot of false-positives. With a message like this 'UBSAN: Undefined behaviour in...' with a call trace that follows.
Reworked so that when building a allmodconfig kernel that turns everything into '=m' or '=y' will turn off
UBSAN_ALIGNMENT.Suggested-by Arnd Bergmann <[email protected]>Signed-off-by Anders Roxell <[email protected]>---
Acked-by Andrey Ryabinin <[email protected]>
Quoted 8 lines
Quoted 2 lines
Confused. Why does allmodconfig result in UBSAN warnings?
UBSAN warnings is a result of enabling noisy
CONFIG_UBSAN_ALIGNMENTwhich is disabled by default if HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
It's noisy even if don't have efficient unaligned access, e.g. people often add
__cacheline_aligned_in_smpin structs, but forget to align allocations of such struct
(kmalloc()give 8-byte alignment in worst case).
That would be a fixable issue, but there is another one that I looked at with Anders: We have a number of list_for_each_entry_safe() loops that use a list_head on the stack and add objects of a type with large alignment. When list_for_each_entry_safe() gets to the end of that list, it sees a pointer to an unaligned structure starting few bytes before the list_head on stack. The only element of that structure that is ever used is that list_head, so there is no actual problem, but the warning triggers nonetheless.
Arnd