linux-kernel - Re: [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count to counter

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: <1545e7c77675c9a0574a7582ee5f0c969c01419e.camel@sipsolutions.net>
Date:   Thu, 08 Oct 2020 08:42:22 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Kees Cook <keescook@...omium.org>
Cc:     Shuah Khan <skhan@...uxfoundation.org>, gregkh@...uxfoundation.org,
        rafael@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count
 to counter_atomic32

On Wed, 2020-10-07 at 13:43 -0700, Kees Cook wrote:
> > > > I actually wonder if this should use refcount_t just because it is
> > > > designed to be an alway-unique value. It is hard to imagine ever causing
> > > > this to overflow, but why not let it be protected?
> > > > 
> > > 
> > > This is one of the cases where devcd_count doesn't guard lifetimes,
> > > however if it ever overflows, refcount_t is a better choice.
> > > 
> > > If we decide refcount_t is a better choice, I can drop this patch
> > > and send refcount_t conversion patch instead.
> > > 
> > > Greg! Any thoughts on refcount_t for this being a better choice?
> > 
> > I'm not Greg, but ... there's a 5 minute timeout. So in order to cause a
> > clash you'd have to manage to overflow the counter within a 5 minute
> > interval, otherwise you can actually reuse the numbers starting again
> > from 0 without any ill effect.
> 
> That's not true as far as I can see: there's no reset in here. It's a
> global heap variable with function-level visibility (note the "static"),
> so it is only ever initialized once:

Yes, obviously it is a static variable. You'll note that I also never
claimed anything regarding reset.

What I said was two things (perhaps with too many words :-) ):
 1) each value that we derive from this ever-incrementing (modulo 2^32)
    variable only get used for a limited amount of time (max. 5 minutes)
 2) if you manage to overflow within 5 minutes, then the following
    device_add() will just fail and nothing else/bad will happen

Therefore, there's no problem with wrapping, and IMHO it'd be *better*
than saturating because (1) means that the wrapping almost certainly
doesn't matter, and (2) means that even if you do manage to wrap and
cause a "clash" (what I wrote in the text you quoted) this is entirely
harmless.

OTOH, if you saturate, then - again under the premise of actually
getting there, however unlikely it may be - you are afterwards *always*
hitting (2), regardless of (1), which seems counter-productive given
that (1) means that (2) almost certainly won't happen.

IOW, I disagree with you, and think that counter_atomic_32 is more
appropriate here than refcount_t.

johannes