linux-kernel - Re: The sheer number of sparse warnings in the kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <530E9A43.5030003@hurleysoftware.com>
Date:	Wed, 26 Feb 2014 20:52:03 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Greg KH <gregkh@...uxfoundation.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: The sheer number of sparse warnings in the kernel

On 02/26/2014 07:11 PM, H. Peter Anvin wrote:
> On 02/26/2014 03:28 PM, Greg KH wrote:
>>>
>>> What do we need to do to actually make our tools be able to do work for
>>> us?  Newbie projects to clean up?  Trying to get the larger Linux
>>> companies to put resources on it?
>>
>> It's not the easiest "newbie" project as usually the first reflex to
>> "just cast it away" is wrong for a lot of sparse warnings.  I know this
>> from people trying to fix up the sparse warnings in drivers/staging/
>>
>
> I have seen this phenomenon, too.  I also see a bunch of sparse warnings
> which are clearly bogus, for example complaining about sizeof(bool) when
> in bits like:
>
> 		__this_cpu_write(swallow_nmi, false);
>
> So getting this to the point where it is genuinely useful and can be
> made a ubiquitous part of the Linux development process is going to take
> more work and probably involve improvements to sparse so we can indicate
> in the kernel sources when something is okay or removing completely
> bogus warnings, and so on.
>
> The bigger question, again, is what do we need to do to make this
> happen, assuming it is worth doing?  We certainly have had bugs,
> including security holes, which sparse would have caught.  At the same
> time, this kind of work tends to not be the kind that attract the top
> hackers, unfortunately, as it is not "fun".

Well there was that "should we do a bug-fix-only 4.0 release?" message
from Linus back at the 3.12 release.

Or do like Geert does with the build message regressions/fixes. I always scan
that to make sure none of my work is in it :)  (And that could be chunked
up by maintainer).

Just a thought.

Regards,
Peter Hurley
--
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/