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] [day] [month] [year] [list]

Message-ID: <56A7A6DC.1010605@virtuozzo.com>
Date:	Tue, 26 Jan 2016 20:03:24 +0300
From:	Andrey Ryabinin <aryabinin@...tuozzo.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
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 01/26/2016 12:41 AM, Andrew Morton wrote:
> 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?
> 

I don't see anything bad about it. Note, that CONFIG_UBSAN_SANITIZE_ALL=y *only* adds
-fsanitize=* to CFLAGS and this patch removes only CONFIG_UBSAN_SANITIZE_ALL from allyesconfig, but not the CONFIG_UBSAN.

So now, we do allyesconfig build without CONFIG_UBSAN_SANITIZE_ALL (iow without -fsantize=*), but still with CONFIG_UBSAN=y.
Which means that we still build lib/ubsan.c (and with -Wmaybe-uninitialized).

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

I don't know, but it's unlikely that something will be changed here. -Wmaybe-uninitialized will always be prone to
false-positives, simply by definition of it(if GCC could prove that variable is uninitialized it will issue another
warning -Wuninitialized). And since -fsanitize=* causes significant changes in generated code, the influence on
-Wmaybe-uninitialized likely will retain.