linux-kernel - Re: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc

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: <2868b58c.c040.16a546b1ea1.Coremail.huangpei@loongson.cn>
Date:   Thu, 25 Apr 2019 20:14:27 +0800 (GMT+08:00)
From:   huangpei@...ngson.cn
To:     "Peter Zijlstra" <peterz@...radead.org>
Cc:     "Paul Burton" <paul.burton@...s.com>,
        "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
        "akiyks@...il.com" <akiyks@...il.com>,
        "andrea.parri@...rulasolutions.com" 
        <andrea.parri@...rulasolutions.com>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "dlustig@...dia.com" <dlustig@...dia.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "j.alglave@....ac.uk" <j.alglave@....ac.uk>,
        "luc.maranget@...ia.fr" <luc.maranget@...ia.fr>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>,
        "will.deacon@....com" <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "Huacai Chen" <chenhc@...ote.com>
Subject: Re: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb()
 wreckage




> -----原始邮件-----
> 发件人: "Peter Zijlstra" <peterz@...radead.org>
> 发送时间: 2019-04-25 17:09:07 (星期四)
> 收件人: huangpei@...ngson.cn
> 抄送: "Paul Burton" <paul.burton@...s.com>, "stern@...land.harvard.edu" <stern@...land.harvard.edu>, "akiyks@...il.com" <akiyks@...il.com>, "andrea.parri@...rulasolutions.com" <andrea.parri@...rulasolutions.com>, "boqun.feng@...il.com" <boqun.feng@...il.com>, "dlustig@...dia.com" <dlustig@...dia.com>, "dhowells@...hat.com" <dhowells@...hat.com>, "j.alglave@....ac.uk" <j.alglave@....ac.uk>, "luc.maranget@...ia.fr" <luc.maranget@...ia.fr>, "npiggin@...il.com" <npiggin@...il.com>, "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>, "will.deacon@....com" <will.deacon@....com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>, "Huacai Chen" <chenhc@...ote.com>
> 主题: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage
> 
> On Thu, Apr 25, 2019 at 09:33:48AM +0200, Peter Zijlstra wrote:
> 
> > > Let me explain the bug more specific:
> > > 
> > > the bug ONLY matters in following situation:
> > > 
> > > #. more than one cpu (assume cpu A and B) doing ll/sc on same shared
> > > var V
> > > 
> > > #. speculative memory access from A cause A erroneously succeed sc
> > > operation, since the erroneously successful sc operation violate the
> > > coherence protocol. (here coherence protocol means the rules that CPU
> > > follow to implement ll/sc right)
> > > 
> > > #. B succeed sc operation too, but this sc operation is right both
> > > logically and follow the coherence protocol, and makes A's sc wrong
> > > logically since only ONE sc operation can succeed.
> > 
> > (I know your coherence protocol is probably more complicated than MESI,
> > but bear with me)
> > 
> > So A speculatively gets V's line in Exclusive mode, speculates the Lock
> > flag is still there and completes the Store. This speculative store then
> > leaks out and violates MESI because there _should_ only be one Exclusive
> > owner of a line (B).
> > 
> > Something like that?
> 
> So B gets E (from LL), does I on A, then SC succeeds and get M.  A got
> I, speculates E, speculates M and lets the M escape.
> 
> That gets us with 2 competing Ms (which is of course completely
> insane), one wins one looses (at random I presume).
> 
> And this violates atomic guarantees because one operation got lost.


Based on what I was told: 

#. A get E from LL, previous speculative access from A 
kick V out, so A should get I, but A still thought A get E ;

#. and B get E from LL,so B get sc done right; V get sc atomically by B;

#. A still thought it get E, so A get sc done, V get sc by A, but not atomically.


 
> 
> > > If it is not LL/SC but other memory access from B on V, A's ll/sc can
> > > follow the atomic semantics even if A violate the coherence protocol
> > > in the same situation.
> > 
> > *shudder*...
> > 
> >   C atomic-set
> > 
> >   {
> > 	  atomic_set(v, 1);
> >   }
> > 
> >   P1(atomic_t *v)
> >   {
> > 	  atomic_add_unless(v, 1, 0);
> >   }
> > 
> >   P2(atomic_t *v)
> >   {
> > 	  atomic_set(v, 0);
> >   }
> > 
> >   exists
> >   (v=2)
> > 
> > So that one will still work? (that is, v=2 is forbidden)
> 
> But then in this case, P1 has E from LL, P2 does M from the STORE, which
> should cause I on P1. P1 speculates E, speculates M and lets M escape.
> 
> We again have two competing Ms, one wins at random, and v==2 if P1
> wins. This again violates the atomic guarantees and would invalidate
> your claim of it only mattering for competing LL/SC.
> 
> Or am I missing something? (quite likely, I always get confused with
> these things)


北京市海淀区中关村环保科技示范园龙芯产业园2号楼 100095电话: +86 (10) 62546668传真: +86 (10) 62600826www.loongson.cn本邮件及其附件含有龙芯中科技术有限公司的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部 分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 

This email and its attachments contain confidential information from Loongson
Technology Corporation Limited, which is intended only for the person or entity
whose address is listed above. Any use of the information contained herein in
any way (including, but not limited to, total or partial disclosure,
reproduction or dissemination) by persons other than the intended recipient(s)
is prohibited. If you receive this email in error, please notify the sender by
phone or email immediately and delete it.