Messages in this thread | | | Date | Thu, 5 Feb 2009 09:26:58 +0100 | Subject | Re: [PATCH] Kbuild: Disable the -Wformat-security gcc flag | From | Floris Kraak <> |
| |
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?
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
| |