linux-kernel - Re: [PATCH] mm/rmap: Convert from atomic_t to refcount_t on anon

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: <20210820082457.GA16784@willie-the-truck>
Date:   Fri, 20 Aug 2021 09:24:58 +0100
From:   Will Deacon <will@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Xiyu Yang <xiyuyang19@...an.edu.cn>,
        Alistair Popple <apopple@...dia.com>,
        Yang Shi <shy828301@...il.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Hugh Dickins <hughd@...gle.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, yuanxzhang@...an.edu.cn,
        Xin Tan <tanxin.ctf@...il.com>,
        Will Deacon <will.deacon@....com>,
        David Howells <dhowells@...hat.com>, keescook@...omium.org
Subject: Re: [PATCH] mm/rmap: Convert from atomic_t to refcount_t on
 anon_vma->refcount

On Fri, Aug 20, 2021 at 10:16:18AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 20, 2021 at 08:43:40AM +0200, Peter Zijlstra wrote:
> 
> > Fine with me; although the immediate complaint from Andrew was about
> > size, hence my UD1 hackery.
> > 
> > > So if we do this, I think it should be something like
> > > 
> > >    static inline __must_check bool refcount_dec_and_test(refcount_t *r)
> > >    {
> > >         asm_volatile_goto (LOCK_PREFIX "decl %[var]\n\t"
> > >                 "jz %l[cc_zero]\n\t"
> > >                 "jl %l[cc_error]"
> > >                 : : [var] "m" (r->refs.counter)
> > >                 : "memory" : cc_zero, cc_error);
> > > 
> > >         return false;
> > > 
> > >    cc_zero:
> > >         return true;
> > >    cc_error:
> > >         refcount_warn_saturate(r, REFCOUNT_SUB_UAF);
> > >         return false;
> > >    }
> > > 
> > > and we can discuss whether we could improve on the
> > > refcount_warn_saturate() separately.
> > 
> > I can do the refcount_warn_saturate() change separately.
> > 
> > Let me go check how small I can get it...
> 
> gcc-10.2.1, x86_64-defconfig
> 
> kernel/event/core.o-inline-ud1:     96454
> kernel/event/core.o-outofline-ud1:  96604
> kernel/event/core.o-outofline-call: 97072
> 
> (42 refcount_warn_saturate/ud1 instances in that file,
>  10 of which are refcount_dec_and_test)

Is that with the saturation moved to the UD handler as well? I think it
would be good to keep that as close to the point at which we detect the
problem as we can, so perhaps we can inline that part and leave the
diagnostics to the exception handler?

Will