linux-kernel - Re: linux-next: Tree for April 10 (arch/x86)

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

Date:	Mon, 14 Apr 2008 10:34:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	mingo <mingo@...hat.com>, tglx <tglx@...utronix.de>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for April 10 (arch/x86)

* Al Viro <viro@...IV.linux.org.uk> wrote:

> On Mon, Apr 14, 2008 at 10:12:20AM +0200, Ingo Molnar wrote:
> 
> > well, gcc does not "recover", we _gave_ it the format string as a 
> > constant, and do so in 99.9% of the cases. It is a totally 
> > well-specified thing.
> 
> It is an undefined behaviour according to any variant of C standard. 
> Sorry, printf() is not magic and it does _not_ have special calling 
> conventions.

... but reality called in and gcc added printf format checks as a gcc 
extension and even modifies the code to make it safe when the user gets 
it "wrong".

why? Because vararg is a dangerous concept as specified and strong but 
meaningful type checking should be enforced across such places. And our 
goal is to build better software and avoid bugs that can be avoided, not 
to follow standards where they are _stupid_.

> What is not right is the lack of ability to define new conversions.  
> If we could do that, we would kill the absolute majority of casts - 
> and remain within normal C limits...

sure. I dont actually care that much how it's solved - via extending the 
concept of varargs or via working it around where it hurts most. What 
matters is that the current situation is suboptimal. The present 
"solution" uglifies the code and more ugly code is always more 
dangerous.

But it's even worse: bogus warnings also reduce the psychological 
threshold to adding stupid casts - if you have to add casts in a printk 
that looks senseless then why not circumvent _other_ warnings that look 
senseless?

Excessive false positives are actively harmful to software quality 
because they teach people to ignore warnings.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/