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]>
---
lib/Kconfig.ubsan | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 98fa559ebd80..a2ae4a8e4fa6 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -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
--
2.19.2
On 12/17/18 6:03 PM, Anders Roxell wrote:
> 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]>
> lib/Kconfig.ubsan | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 98fa559ebd80..a2ae4a8e4fa6 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -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
>
On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]> wrote:
>
>
> On 12/17/18 6:03 PM, Anders Roxell wrote:
> > 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]>
>
Confused. Why does allmodconfig result in UBSAN warnings?
On 1/30/19 4:36 AM, Andrew Morton wrote:
> On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]> wrote:
>
>>
>>
>> On 12/17/18 6:03 PM, Anders Roxell wrote:
>>> 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]>
>>
>
> 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).
On Wed, Jan 30, 2019 at 6:12 PM Andrey Ryabinin <[email protected]> wrote:
> On 1/30/19 4:36 AM, Andrew Morton wrote:
> > On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <[email protected]> wrote:
> >> On 12/17/18 6:03 PM, Anders Roxell wrote:
> >>> 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]>
> >>
> >
> > 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).
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