linux-kernel - RE: BUG report about ipt_do

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, 11 Oct 2013 09:50:24 +0800
From:	"Wang, Yalin" <Yalin.Wang@...ymobile.com>
To:	'Will Deacon' <will.deacon@....com>
CC:	"'linux-arm-msm-owner@...r.kernel.org'" 
	<linux-arm-msm-owner@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Peng, Arthur" <Arthur.Peng@...ymobile.com>,
	"Zhang, Bojie" <Bojie.Zhang@...ymobile.com>,
	"Gu, Youcai 1 (EXT)" <Youcai1.Gu@...ymobile.com>,
	"Alevoor, Raghavendra 2" <Raghavendra.Alevoor@...ymobile.com>
Subject: RE: BUG report about ipt_do_table( )

Hi  Will,

Maybe I know your meaning ,
If it use spinlock to protected the shared data,
The bug will not happen, because spinlock will 
Use DSB( )  to sync .
Unluckily, here, it use a special seqcount_t( ) (see get_counters( ) function)
To make sure there is no others using the old data,
Before release the old data, this is much like RCU
Work, but RCU use rcu_assign_pointer( ) -->
Which use smp_wmb( ) , so it's safe,  am I right ?

In my patch, I use mb( ), because this macro
Is DSB( ) , while smp_wmb( ) is DMS( ),
I just think DSB is much strict than DMS,
mmm..  so , DSM( )  or DMS ( )  are both ok ?

The whitepaper I use is here:
https://www.google.com/#q=cortex+a15+microarchitecture

the first: [PDF] Exploring the Design of the Cortex-A15 Processor - ARM

I just search in Google, and you know that qcom don't release
Much document about its krait cpu's micro architecture details,
I just use cortex-a15 for a reference, I am not sure if their 
pipeline ( load/store unit) are the same,
if you have cortex-a15 micro architecture details document,
I am very appreciated that you can share to  me . :)

Thanks 

-----Original Message-----
From: Will Deacon [mailto:will.deacon@....com] 
Sent: Thursday, October 10, 2013 10:19 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-owner@...r.kernel.org'; linux-kernel@...r.kernel.org; Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )

On Thu, Oct 10, 2013 at 12:26:38PM +0100, Wang, Yalin wrote:
> Hi  Will ,

Hello,

> Seems your patch is better than mine,
> It make sure newinfo->initial_entries  update is Seen by others .
> 
> I will test by your patches , and update to you ASAP .

Thanks.

> I have another questions about this  BUG, Since all shared data will 
> have this problem especially Shared between different CPUs,
> 
> This means all shared data need a smp_wmb() , after One CPU update it 
> ?

Only if the ordering of observability matters and isn't enforced by other mechanisms (e.g. locks).

> But I see not all shared data are updated by this way, And kernel 
> works well .  Why ??  a little curious .

Again, the barriers tend to be hidden inside things like locking primitives, atomics, I/O accessors etc.

> Another is that , I read cortex-a15 whitepaper , It says :
> 
> Load/Store cluster
> § All Load/Store, data transfers and cache maintenance operations § 
> Partially out-of-order, 1 Load and 1 Store executed per cycle § Load 
> cannot bypass a Store, Store cannot bypass a Store

It's hard to interpret this out of context. Please can you point me at the whitepaper? Also, I was talking from the perspective of the architecture and you're not using an A15 afaik.

> !! Store can't   bypass  store !! , but in this BUG , it seems later store can
> Be wrote into cache even before  the earlier store completed !
> Am I right ?

The architecture requires stores to be observed in program order from the perspective of the CPU issuing them, but there aren't ordering guarantees for stores to different locations when observed by a different CPU.

Will