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:   Tue, 21 Jul 2020 21:51:32 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     David Howells <dhowells@...hat.com>,
        Xiaoming Ni <nixiaoming@...wei.com>,
        David Windsor <dwindsor@...il.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        Paul Moore <paul@...l-moore.com>, edumazet@...gle.com,
        paulmck@...nel.org, shakeelb@...gle.com,
        James Morris <jamorris@...ux.microsoft.com>,
        alex.huangjianhui@...wei.com, dylix.dailei@...wei.com,
        chenzefeng2@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Convert nsproxy, groups, and creds to refcount_t

On Tue, Jul 21, 2020 at 11:44:53AM -0700, Kees Cook wrote:
> On Tue, Jul 21, 2020 at 11:51:04AM +0100, David Howells wrote:
> > Kees Cook <keescook@...omium.org> wrote:
> > 
> > > > Should mm->mm_users also be replaced by refcount_t?
> > > 
> > > I'll say "yes". :)
> > > https://lore.kernel.org/lkml/1487671124-11188-1-git-send-email-elena.reshetova@intel.com/
> > > 
> > > > In addition, is it better to change all variables that use
> > > > atomic_dec_and_test to control the release process to refconut_t?
> > > 
> > > For the most part, yes. The following may find a lot of them:
> > > scripts/coccinelle/api/atomic_as_refcounter.cocci
> > 
> > I've been gradually undoing some of the conversions as there's no equivalent
> > of atomic_add_return() and atomic_dec_return() that allow me to log the
> > altered refcount through a tracepoint.
> 
> Please do not _undo_ the changes; just add the API you need.

add_return and sub_return are horrible interface for refcount, which is
the problem.

If you meant: refcount_dec(), but want the old value for tracing, you
want a different ordering than if you wanted to do
refcount_dec_and_test(); dec_return can't know this.

David, would something like a __refcount_*() API work where there is a
3rd argument (int *), which, if !NULL, will be assigned the old value?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ