linux-kernel - Re: [PATCH] ubsan: fix tree-wide -Wmaybe-uninitialized false positives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160125134136.cee4919a8453c4753f177c3b@linux-foundation.org>
Date:	Mon, 25 Jan 2016 13:41:36 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc:	<fengguang.wu@...el.com>, <linux-kernel@...r.kernel.org>,
	<kbuild-all@...org>
Subject: Re: [PATCH] ubsan: fix tree-wide -Wmaybe-uninitialized false
 positives

On Mon, 25 Jan 2016 19:01:34 +0300 Andrey Ryabinin <aryabinin@...tuozzo.com> wrote:

> -fsanitize=* options makes GCC less smart than usual and increase number
> of 'maybe-uninitialized' false-positives. So this patch does two things:
>  * Add -Wno-maybe-uninitialized to CFLAGS_UBSAN which will disable all
>    such warnings for instrumented files.
>  * Remove CONFIG_UBSAN_SANITIZE_ALL from all[yes|mod]config builds. So
>    the all[yes|mod]config build goes without -fsanitize=* and still with
>    -Wmaybe-uninitialized.

hm, that's a bit sad.

We have no means of working out whether we should re-enable
maybe-uninitialized for later gcc's, as they become smarter about this.
What do we do, just "remember" to try it later on?

Do you know if this issue is on the gcc developer' radar?