linux-kernel - Re: smatch 1.53 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a63d67fe0906050652k51321f18h4588d54954b3eb78@mail.gmail.com>
Date:	Fri, 5 Jun 2009 15:52:07 +0200
From:	Dan Carpenter <error27@...il.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: smatch 1.53 released

On 6/4/09, Andi Kleen <andi@...stfloor.org> wrote:
> Thanks for the description.
>
>> So basically you grep for locking functions and you set the state
>> based on that, then you grep for return statements and check that the
>
> When you say "you" you mean smatch is doing that on its own
> or does the user need to do that manually?
>

I meant if you were writing a check for a different type of bug.  The
checks that I mentioned are the ones I have written already.

There is also a line between the core smatch and the checks.  The core
understands code flow and the checks call set_state() and get_state()
and print error messages.  The core is able to handle any C code but
the checks are project specific.

>> Many of the locking false positives come from places where the unlock
>> happens in a seperate function.  It should be relatively straight
>> forward to make a list functions to say that if frob_the_module()
>> returns -12, or -14 that implies it unlocked a certain lock.  I
>> haven't done this yet.
>
> How would one pass  that list of functions to smatch?
>

You can't right now.  That's the bit that I still need to write.  :/
But as an example, one of the checks has a file smatch_data/ with a
list of functions that allocate memory.  Locking functions would be
the same.

> I understand correctly that right now it's not inter procedural in its
> analysis?
>

The null dereference check is, but none of the other checks are.

When the inter procedural analysis is done, it will mostly be a two
pass system where the first step builds a list of functions and what
they imply and the second pass does the check.  Meaning two kernel
compiles.  Or more likely, people will just use the default lists
which will be updated for -rc1 kernels.

Smatch is still in the very early stages.

regards,
dan carpenter

> -Andi
>
> --
> ak@...ux.intel.com -- Speaking for myself only.
>
--
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/