From: Floris Kraak <randakar@gmail.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: 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>
Subject: Re: [PATCH] Kbuild: Disable the -Wformat-security gcc flag
Date: Thu, 5 Feb 2009 11:15:12 +0100 [thread overview]
Message-ID: <56e1b5710902050215l5b34adb1ofb8a972318ebe353@mail.gmail.com> (raw)
In-Reply-To: <56e1b5710902050026s5a8fd48fhf4a65c05a533dbc3@mail.gmail.com>
On Thu, Feb 5, 2009 at 9:26 AM, Floris Kraak <randakar@gmail.com> wrote:
> On Thu, Feb 5, 2009 at 7:37 AM, Roland Dreier <rdreier@cisco.com> wrote:
>> > Just how many of these warnings are showing up? In the cases you
>> > posted it's presumably no problem, but if the string could either a)
>> > be potentially set by a malicious user or b) accidentally contain
>> > printk format characters then this code has a risk that things could
>> > blow up..
>>
>> I get ~150 of them on an x86 allyesconfig build here (see below). Many
>> but not all are trivial; some at least appear to be passing in strings
>> that come from random hardware/firmware or DNS names etc (ie there's at
>> least a chance of a '%'); and I didn't exhaustively audit to make sure
>> none of them could print something from an unprivileged user.
>>
>
> There are probably some real bugs in there. On the other hand there is
> some overhead to fixing the warnings. Kernel text size increase,
> possibly some CPU overhead from parsing the format string. Hopefully
> none of these calls are in really hot code paths ;-)
> As I noted applying a patch that does the reverse and enables the
> check instead is perfectly acceptable to me. Long term somebody
> probably needs to go through all of them and fix (most of) them
> anyway.
>
> What remains an open question to me though is what to do with cases
> where the warning not only can be ignored but literally should be. eg.
> when there is zero chance of something unexpected getting passed in
> and 'fixing' it would just bloat the kernel.
> Can sparse be used to check this kind of thing for correctness?
>
Example:
kernel/power/main.c:717: warning: format not a string literal and no
format arguments
This complains about:
..
if (!rtc) {
printk(warn_no_rtc);
goto done;
}
..
So what is this "warn_no_rtc" thing?
static char warn_no_rtc[] __initdata =
KERN_WARNING "PM: no wakealarm-capable RTC driver is ready\n";
That's pretty much GCC failing to recognize that the format is a
string literal and then complaining that it isn't.
How do we make the warning go away without growing the kernel text?
Given the use of __initdata flags I'm not even sure if doing the
obvious printk("%s", warn_no_rtc) isn't going to introduce a subtle
bug somehow..
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
next prev parent reply other threads:[~2009-02-05 10:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 14:28 Floris Kraak
2009-02-04 22:14 ` Sam Ravnborg
2009-02-04 22:26 ` Roland Dreier
2009-02-04 23:48 ` Robert Hancock
2009-02-05 6:37 ` Roland Dreier
2009-02-05 8:26 ` Floris Kraak
2009-02-05 10:15 ` Floris Kraak [this message]
2009-02-05 10:27 ` Andreas Schwab
2009-02-05 10:50 ` Floris Kraak
2009-02-05 21:52 ` Roland Dreier
2009-02-10 21:11 ` Kyle Moffett
2009-02-10 21:56 ` Floris Kraak
2009-02-10 20:24 ` Pavel Machek
2009-02-10 21:48 ` Floris Kraak
2009-05-15 10:23 ` Pekka Enberg
2009-05-15 13:28 ` Floris Kraak
2009-05-15 20:42 ` Pekka Enberg
2009-05-15 22:09 ` Floris Kraak
2009-06-14 20:50 ` Sam Ravnborg
2009-06-15 5:54 ` Pekka J Enberg
2009-06-15 8:02 ` Floris Kraak
2009-06-26 22:15 ` Sam Ravnborg
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=56e1b5710902050215l5b34adb1ofb8a972318ebe353@mail.gmail.com \
--to=randakar@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hancockrwd@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=sam@ravnborg.org \
--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®