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]
Date:   Fri, 17 Mar 2017 09:02:16 -0400
From:   Jeff Layton <jlayton@...chiereds.net>
To:     Trond Myklebust <trondmy@...marydata.com>,
        "elena.reshetova@...el.com" <elena.reshetova@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "ralf@...ux-mips.org" <ralf@...ux-mips.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "ishkamiel@...il.com" <ishkamiel@...il.com>,
        "bfields@...ldses.org" <bfields@...ldses.org>,
        "steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
        "nhorman@...driver.com" <nhorman@...driver.com>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "jreuter@...na.de" <jreuter@...na.de>,
        "santosh.shilimkar@...cle.com" <santosh.shilimkar@...cle.com>,
        "linux-hams@...r.kernel.org" <linux-hams@...r.kernel.org>,
        "dwindsor@...il.com" <dwindsor@...il.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "zyan@...hat.com" <zyan@...hat.com>,
        "sage@...hat.com" <sage@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "vyasevich@...il.com" <vyasevich@...il.com>,
        "linux-x25@...r.kernel.org" <linux-x25@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>
Subject: Re: [PATCH 01/23] net, sunrpc: convert rpc_cred.cr_count from
 atomic_t to refcount_t

On Fri, 2017-03-17 at 12:50 +0000, Trond Myklebust wrote:
> On Fri, 2017-03-17 at 14:10 +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> > 
> > Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
> > Signed-off-by: Hans Liljestrand <ishkamiel@...il.com>
> > Signed-off-by: Kees Cook <keescook@...omium.org>
> > Signed-off-by: David Windsor <dwindsor@...il.com>
> > ---
> >  include/linux/sunrpc/auth.h |  8 ++++----
> >  net/sunrpc/auth.c           | 12 ++++++------
> >  2 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/include/linux/sunrpc/auth.h
> > b/include/linux/sunrpc/auth.h
> > index b1bc62b..bd36e0b 100644
> > --- a/include/linux/sunrpc/auth.h
> > +++ b/include/linux/sunrpc/auth.h
> > @@ -15,7 +15,7 @@
> >  #include <linux/sunrpc/msg_prot.h>
> >  #include <linux/sunrpc/xdr.h>
> >  
> > -#include <linux/atomic.h>
> > +#include <linux/refcount.h>
> >  #include <linux/rcupdate.h>
> >  #include <linux/uidgid.h>
> >  #include <linux/utsname.h>
> > @@ -68,7 +68,7 @@ struct rpc_cred {
> >  #endif
> >  	unsigned long		cr_expire;	/* when to gc
> > */
> >  	unsigned long		cr_flags;	/* various
> > flags */
> > -	atomic_t		cr_count;	/* ref count */
> > +	refcount_t		cr_count;	/* ref count */
> > 
> 
> NACK. That's going to be hitting WARN_ONCE(!refcount_inc_not_zero(r),
> "refcount_t: increment on 0; use-after-free.\n") like there's no
> tomorrow...
> 
> Please stop with these automated conversions. They are going to cause a
> lot more bugs than they fix.
> 

Agreed. These patchsets are touching places where we've already banged
out most of the refcounting bugs. I'm against doing large scale
conversions like this without a damned good reason.

I think it may be best to do this sort of thing in a more piecemeal
fashion. Pick a subsystem or two and do the conversions there to prove
that they're better than what we have. If the subsystem already has
problems with its refcounting, then so much the better. Point to bugs
that this new infrastructure helped find.

Encourage people to adopt your new infrastructure as new refcounted
objects are introduced into the kernel. You might even consider a LWN
article about this.

Eventually we'll get around to changing existing code to use it, once
there is a sufficient advantage to doing so. Most likely when we're
reworking the code for other reasons, or when we're chasing some horrid
refcounting bug and think that this might help find it.
-- 
Jeff Layton <jlayton@...chiereds.net>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ