linux-kernel - Re: [PATCH v2] coccinelle: assign signed result to unsigned variable

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

Date:	Sat, 3 Oct 2015 09:09:22 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Andrzej Hajda <a.hajda@...sung.com>
cc:	julia.lawall@...6.fr,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Gilles Muller <Gilles.Muller@...6.fr>,
	Michal Marek <mmarek@...e.com>,
	Nicolas Palix <nicolas.palix@...g.fr>,
	kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
	cocci@...teme.lip6.fr, elfring@...rs.sourceforge.net
Subject: Re: [PATCH v2] coccinelle: assign signed result to unsigned
 variable

Some comments:

If you get 20 good results and 22 false positives, I'm not sure whether 
high confidence is justified.  That seemes more like moderate confidence.

On the other hand, I think it is possible to get rid of the false 
positives.  The false positives are coming from the fact that you have:

if ( \( vu < 0 \| vu <= 0 \) ) S1 else S2

This can be flipped around to

if ( ! \( vu < 0 \| vu <= 0 \) ) S2 else S1

and then when we propagate the ! into the disjunction, we get v >= 0 for 
the first condition and v > 0 for the second condition.  v >= 0 is always 
true, so it could be reasonable to highlight it, but v > 0 is a perfectly 
reasonable test for an unsigned value, and is where you are getting the 
false positives from.  If you want to get rid of both v >= 0 and v < 0 
then you can just put disable neg_if in the initial @@, just after r, ie

@r disable neg_if@

On the other hand, if you want to keep the warning on v >= 0 but drop the 
warning on v > 0, then you will have to split the rules and put the 
disable neg_if on the one for v <= 0.

I think it would also be reasonable to merge the proposed semantic 
patches.  I guess this one gives most of the results anyway?

With recursive_includes, I got 70 results, at least 20 of which should be 
false positives due to the MB case.

julia
--
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/