linux-kernel - Re: [PATCH v3 00/11] Introduce Simple atomic counters

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

Message-ID: <20201110184903.GG29398@kadam>
Date:   Tue, 10 Nov 2020 21:49:03 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Peter Zijlstra <peterz@...radead.org>, rafael@...nel.org,
        Will Deacon <will@...nel.org>, linux-kselftest@...r.kernel.org,
        joel@...lfernandes.org, rric@...nel.org, shuah@...nel.org,
        devel@...verdev.osuosl.org, minyard@....org, corbet@....net,
        surenb@...gle.com, linux-doc@...r.kernel.org,
        linux-acpi@...r.kernel.org, lenb@...nel.org, tkjos@...roid.com,
        arnd@...db.de, bp@...en8.de,
        Shuah Khan <skhan@...uxfoundation.org>,
        openipmi-developer@...ts.sourceforge.net, mchehab@...nel.org,
        maco@...roid.com, christian@...uner.io, linux-edac@...r.kernel.org,
        tony.luck@...el.com, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, arve@...roid.com,
        james.morse@....com, hridya@...gle.com, johannes@...solutions.net
Subject: Re: [PATCH v3 00/11] Introduce Simple atomic counters

On Fri, Oct 16, 2020 at 03:51:25PM -0700, Kees Cook wrote:
> On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote:
> > That's like saying: "I'm too lazy to track what I've looked at already".
> > You're basically proposing to graffiti "Kees was here -- 16/10/2020" all
> > over the kernel. Just so you can see where you still need to go.
> > 
> > It says the code was (assuming your audit was correct) good at that
> > date, but has no guarantees for any moment after that.
> 
> That kind of bit-rot marking is exactly what I would like to avoid: just
> putting a comment in is pointless. Making the expectations of the usage
> become _enforced_ is the goal. And having it enforced by the _compiler_
> is key. Just adding a meaningless attribute that a static checker
> will notice some time and hope people fix them doesn't scale either
> (just look at how many sparse warnings there are).

Most Sparse warnings are false positives.  People do actually fix the
ones which matter.

I think this patchset could be useful.  I'm working on a refcounting
check for Smatch.  I want to warn about when we forget to drop a
reference on an error path.  Right now I just assume that anything with
"error", "drop" or "->stats->" in the name is just a counter.

regards,
dan carpenter