linux-kernel - smatch 1.51 released

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

Message-ID: <a63d67fe0903100539r6ca3d789m4be81239eba2bf3b@mail.gmail.com>
Date:	Tue, 10 Mar 2009 15:39:46 +0300
From:	Dan Carpenter <error27@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	smatch-discuss <smatch-discuss@...ts.sf.net>
Subject: smatch 1.51 released

Smatch follows the kernel naming scheme so odd numbers are devel
releases.  The .51 means over half finished.

Smatch is available from:  http://repo.or.cz/w/smatch.git/

This is a reimplementation that doesn't use gcc code.  The check are
written in C instead of Perl.  It's still fairly simple to write
tests.  It's a bazillion times better than the original in almost
every way.  Unfortunately it still sucks a little.  There is a
shocking high percent of false positives.

To test the whole kernel use:
make -k CHECK=/path/to/smatch C=y bzImage | tee warns.txt

To test a single file use the smatch_scripts/kchecker script.
kchecker drivers/acpi/acpica/nsxfobj.c

The output is labeled either error, warn, or info.  So "grep -w error:
warns.txt"  Most of the "info" stuff is for the
smatch_scripts/find_null_params.sh script.  Even though it's labeled
"info", grepping for "info: ignoring unreachable code." sometimes
turns up bugs.

Smatch works by tracking the flow of code.
int a;  <- state is uninitialized.
if (b) {
       a = foo();  <- state is initialized.
       if (a) {
              bar(a);  <- state is non zero.
       }
}
baz(a);  <- state is undefined.  possibly uninitialized, zero, or non-zero

It also understands some simple implications.  For example the
following code doesn't generate an error.
	ab = kzalloc();
	if (NULL == ab) {
		ret = -1;
		goto foo;
	}
   ...
foo:
	if (ret) {
		return;
	}
	ab->a = 1;  // <-- This is not an error.

There are a couple functions that use a lot of memory to check.  If
you have a gig of memory you should be ok.  If it crashes use
"kchecker --valgrind" to generate a stack dump and mail that to me.

If you can't figure out why an error gets generated it's probably a
bug.  Use "kchecker --debug" to try figure out what went wrong.

regards,
dan carpenter
--
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/