linux-hardening - Re: -Wformat-trunctation with `make W=1`

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: <ea7a604f-b3b7-40ef-bea2-27c2e83ceef1@app.fastmail.com>
Date: Wed, 11 Sep 2024 07:05:44 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <kees@...nel.org>,
 "Andy Shevchenko" <andriy.shevchenko@...el.com>
Cc: linux-hardening@...r.kernel.org
Subject: Re: -Wformat-trunctation with `make W=1`

On Wed, Sep 11, 2024, at 00:26, Kees Cook wrote:
> On Mon, Sep 09, 2024 at 04:26:03PM +0300, Andy Shevchenko wrote:
>> Recently I'm trying to compile my (almost) x86_64_defconfig based kernel with
>> `make W=1` while having CONFIG_WERROR=y. With a handful of patches I was able
>> to achieve that with clang-18, however GCC 14.2.0 issues a lot of additional
>> warnings that are mostly related to -Wformat-truncation [1]. Any suggestions,
>> plans, comments on how to address them?
>> 
>> [1]: https://paste.debian.net/hidden/46106f2a/
>
> Since it's behind W=1, fixing those issues hasn't been a very high
> priority. That said, I would love to see it done. Patches have slowly
> been landing for various W=1 things related to the -Wstringop-... and
> -Wformat... options, though. But I don't think there has been a
> concerted effort to wipe them out completely. And at least sometimes
> these warnings are effectively false positives, related to unexpected
> behaviors in GCC's value range tracking, though that has mostly been an
> issue for getting -Warray-bounds to build cleanly.
>
> As for fixing them, I think one will need to just look at each instance
> one at a time to figure out the best solution.

I have a series from earlier this year, let me see what I had
in there:

 -Wformat-truncation triggers in 133 files with arm64 allmodconfig,
  which is more than any other W=1 warnings. Addressing them
  individually is probably a good idea, but most of the other
  W=1 warnings seem more helpful if we can just enable them
  after a few patches.
 -Wformat-truncation-non-kprintf only happens in a single file
  and we should fix that. We can probably just enable the
  default -Wformat warnings on clang at last..
 -Wunused-const-variable=2 needs a lot of patches but they are
  all trivial (mostly extraneous of_match_ptr()), just need to
  be split up better. My tree builds  randconfig cleanly with
  this enabled.
 -Wtautological-constant-out-of-range-compare needs four
  more patches that I have sent previously
 -Wstringop-truncation can be enabled globally
 -Woverride-init just needs to be disabled in a couple of
  key places that intentionally use defaults
 -Wmissing-format-attribute triggers in only 9 files, but
  I don't think I have patches for those.
 -Wformat-overflow= triggers in 15 files with gcc but 35 with
  clang, I don't have patches for these.
 -Wunused-but-set-variable triggers in 8 files, I sent some
  patches for these in the past.
 -Wenum-enum-conversion has 93 files with warnings in clang-20
 -Wvoid-pointer-to-enum-cast shows up in 19 files with clang-20

       Arnd