| 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
| ||
|
Message-ID: <592bc84.c106.16a57936acf.Coremail.huangpei@loongson.cn>
Date: Fri, 26 Apr 2019 10:57:20 +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: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix
loongson_llsc_mb() wreckage
> -----原始邮件-----
> 发件人: "Peter Zijlstra" <peterz@...radead.org>
> 发送时间: 2019-04-25 21:31:05 (星期四)
> 收件人: 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: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage
>
> On Thu, Apr 25, 2019 at 08:51:17PM +0800, huangpei@...ngson.cn wrote:
>
> > > So basically the initial value of @v is set to 1.
> > >
> > > Then CPU-1 does atomic_add_unless(v, 1, 0)
> > > CPU-2 does atomic_set(v, 0)
> > >
> > > If CPU1 goes first, it will see 1, which is not 0 and thus add 1 to 1
> > > and obtains 2. Then CPU2 goes and writes 0, so the exist clause sees
> > > v==0 and doesn't observe 2.
> > >
> > > The other way around, CPU-2 goes first, writes a 0, then CPU-1 goes and
> > > observes the 0, finds it matches 0 and doesn't add. Again, the exist
> > > clause will find 0 doesn't match 2.
> > >
> > > This all goes unstuck if interleaved like:
> > >
> > >
> > > CPU-1 CPU-2
> > >
> > > xor t0, t0
> > > 1: ll t0, v
> > > bez t0, 2f
> > > sw t0, v
> > > add t0, t1
> > > sc t0, v
> > > beqz t0, 1b
> > >
> > > (sorry if I got the MIPS asm wrong; it's not something I normally write)
> > >
> > > And the store-word from CPU-2 doesn't make the SC from CPU-1 fail.
> > >
> >
> > loongson's llsc bug DOES NOT fail this litmus( we will not get V=2)；
> >
> > only speculative memory access from CPU-1 can "blind" CPU-1(here blind means do ll/sc
> > wrong）, this speculative memory access can be observed corrently by CPU2. In this
> > case, sw from CPU-2 can get I , which can be observed by CPU-1, and clear llbit，then
> > failed sc.
>
> I'm not following, suppose CPU-1 happens as a speculation (imagine
> whatever code is required to make that happen before). CPU-2 sw will
> cause I on CPU-1's ll but, as in the previous email, CPU-1 will continue
> as if it still has E and complete the SC.
>
> That is; I'm just not seeing why this case would be different from two
> competing LL/SCs.
>
I get your point. I kept my eye on the sw from CPU-2, but forgot the speculative
mem access from CPU-1.
There is no difference bewteen this one and the former case.
=========================================================================
V = 1
CPU-1 CPU-2
xor t0, t0
1: ll t0, V
beqz t0, 2f
/* if speculative mem
access kick cacheline of
V out, it can blind CPU-1
and make CPU-1 believe it
still hold E on V, and can
NOT see the sw from CPU-2
actually invalid V, which
should clear LLBit of CPU-1,
but not */
sw t0, V // just after sw, V = 0
addiu t0, t0, 1
sc t0, V
/* oops, sc write t0(2)
into V with LLBit */
/* get V=2 */
beqz t0, 1b
nop
2:
================================================================================
if speculative mem access *does not* kick out cache line of V, CPU-1 can see sw
from CPU-2, and clear LLBit, which cause sc fail and retry, That's OK
北京市海淀区中关村环保科技示范园龙芯产业园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.
Powered by blists - more mailing lists