mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Floris Kraak <randakar@gmail.com>
To: Mike Isely <isely@pobox.com>
Cc: Roland Dreier <rdreier@cisco.com>,
	Robert Hancock <hancockrwd@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Trivial Patch Monkey <trivial@kernel.org>,
	Andreas Schwab <schwab@suse.de>
Subject: Re: [PATCH]: Cleanup: Remove gcc format string warnings when  compiling with -Wformat-security (was: Re: [PATCH] Kbuild: Disable the  -Wformat-security gcc flag)
Date: Thu, 5 Feb 2009 16:38:41 +0100	[thread overview]
Message-ID: <56e1b5710902050738n33616bdfuf9ca0b157d8d260f@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0902050908400.7489@cnc.isely.net>

On Thu, Feb 5, 2009 at 4:22 PM, Mike Isely <isely@isely.net> wrote:
>> ---
>> Cleanup: Remove gcc format string warnings when compiling with -Wformat-security
>>
>> When compiling the kernel with an allyesconfig and the gcc flags
>> -Wformat and -Wformat-security the build process emits 135 warnings
>> along these lines:
>>
>> init/main.c:557: warning: format not a string literal and no format arguments
>> init/initramfs.c:582: warning: format not a string literal and no
>> format arguments
>> arch/x86/kernel/dumpstack.c:115: warning: format not a string literal
>> and no format arguments
>> ...
>>
>> While many of these warnings are harmless - the format string is
>> statically set within the kernel itself and is known to not contain
>> any format qualifiers - a number of them are potentially less so.
>> This patch fixes all known call sites emitting this warning.
>>
>
>   [...]
>
>> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
>> b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
>> index fa304e5..42ccab0 100644
>> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
>> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
>> @@ -1967,7 +1967,7 @@ static void pvr2_hdw_setup_low(struct pvr2_hdw *hdw)
>>       if (!pvr2_hdw_dev_ok(hdw)) return;
>>
>>       for (idx = 0; idx < hdw->hdw_desc->client_modules.cnt; idx++) {
>> -             request_module(hdw->hdw_desc->client_modules.lst[idx]);
>> +             request_module("%s", hdw->hdw_desc->client_modules.lst[idx]);
>>       }
>
> The incoming string in this case comes from a static initialization in
> the same source file (it's a compiled-in list of support module names to
> select based on the specific hardware type that the driver has
> detected).

I'm not surprised ;-)

>
> In both of these cases, the proposed change doesn't do any harm, but it
> does introduce some otherwise pointless inefficiency.
>

I'd *love* to be able to just tell the compiler "hey gcc! we know all
callers are using compiled in static strings here so ignore this one
ok?"
Or even better, for GCC to just detect it itself somehow. Heck, isn't
this the kind of thing that sparse exists for?

One way to solve this without (hopefully) introducing pointless
inefficiency might be to just have printk_noformat() and variants and
make all places that emit this warning call the *_noformat()
alternatives.
But I'm not sure that wouldn't just be introducing pointless
inefficiency to get rid of pointless inefficiency ;-)

> But hey, if this is all with the goal of silencing another script
> casting a big net, I won't stand in the way.

Ubuntu has the gcc flags that cause the build to emit these warnings
enabled by default. Probably some other (security conscious) distro's
enable this as well.
I've posted a patch that enables those flags kernel wide (not sure if
it arrived, nobody replied ;-) ) so that new patches are more likely
to not contain this type of thing.

>
> Acked-By: Mike Isely <isely@pobox.com>
>

Thanks for the ack ;-)

Regards,
Floris
---
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."
  -- Ben Franklin

"The course of history shows that as a government grows, liberty
decreases."
  -- Thomas Jefferson

  reply	other threads:[~2009-02-05 15:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 14:41 Floris Kraak
2009-02-05 14:52 ` Ingo Molnar
2009-02-05 15:22 ` Mike Isely
2009-02-05 15:38   ` Floris Kraak [this message]
2009-02-05 16:34 ` Floris Kraak
2009-02-05 22:13 ` [PATCH]: Cleanup: Remove gcc format string warnings when compiling with -Wformat-security Roland Dreier
2009-02-05 22:41   ` Floris Kraak
2009-02-05 23:42   ` Robert Hancock
2009-02-06 10:36     ` Floris Kraak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56e1b5710902050738n33616bdfuf9ca0b157d8d260f@mail.gmail.com \
    --to=randakar@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hancockrwd@gmail.com \
    --cc=isely@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdreier@cisco.com \
    --cc=sam@ravnborg.org \
    --cc=schwab@suse.de \
    --cc=trivial@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®