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

Message-ID: <202010161541.6DD2D1E@keescook>
Date:   Fri, 16 Oct 2020 15:51:25 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Shuah Khan <skhan@...uxfoundation.org>, corbet@....net,
        gregkh@...uxfoundation.org, shuah@...nel.org, rafael@...nel.org,
        johannes@...solutions.net, lenb@...nel.org, james.morse@....com,
        tony.luck@...el.com, bp@...en8.de, arve@...roid.com,
        tkjos@...roid.com, maco@...roid.com, joel@...lfernandes.org,
        christian@...uner.io, hridya@...gle.com, surenb@...gle.com,
        minyard@....org, arnd@...db.de, mchehab@...nel.org,
        rric@...nel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-acpi@...r.kernel.org, devel@...verdev.osuosl.org,
        openipmi-developer@...ts.sourceforge.net,
        linux-edac@...r.kernel.org, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v3 00/11] Introduce Simple atomic counters

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). So with C's limits,
the API and type enforcement become the principle way to get this done.

So, if there are behavioral patterns we CAN carve away from atomic_t
cleanly (and I think there are), those are the ones I want to work
towards. The "corner case" uses of atomic_t are much less common than
the "big" code patterns like lifetime management (now delegated to and
enforced by refcount_t). My estimation was that _statistics_ (and not
"serial identifiers") was the next biggest code pattern using atomic_t
that could benefit from having its usage isolated. It is not itself a
dangerous code pattern, but it can mask finding them.

Then, at the end of the day, only the corner cases remain, and those can
be seen clearly as they change over time. Since we can never have a
one-time audit be anything other than advisory, we need to make it EASY
to do those kinds of audits so they can be done regularly.

-- 
Kees Cook