linux-kernel - Re: bit fields && data tearing

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:	Sat, 06 Sep 2014 22:07:22 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Peter Hurley <peter@...leysoftware.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jakub Jelinek <jakub@...hat.com>,
	Mikael Pettersson <mikpelinux@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Richard Henderson <rth@...ddle.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Miroslav Franc <mfranc@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
	linux-ia64@...r.kernel.org
Subject: Re: bit fields && data tearing

On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > Hi James,
> > 
> > On 09/04/2014 10:11 PM, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> > >> +And there are anti-guarantees:
> > >> +
> > >> + (*) These guarantees do not apply to bitfields, because compilers often
> > >> +     generate code to modify these using non-atomic read-modify-write
> > >> +     sequences.  Do not attempt to use bitfields to synchronize parallel
> > >> +     algorithms.
> > >> +
> > >> + (*) Even in cases where bitfields are protected by locks, all fields
> > >> +     in a given bitfield must be protected by one lock.  If two fields
> > >> +     in a given bitfield are protected by different locks, the compiler's
> > >> +     non-atomic read-modify-write sequences can cause an update to one
> > >> +     field to corrupt the value of an adjacent field.
> > >> +
> > >> + (*) These guarantees apply only to properly aligned and sized scalar
> > >> +     variables.  "Properly sized" currently means "int" and "long",
> > >> +     because some CPU families do not support loads and stores of
> > >> +     other sizes.  ("Some CPU families" is currently believed to
> > >> +     be only Alpha 21064.  If this is actually the case, a different
> > >> +     non-guarantee is likely to be formulated.)
> > > 
> > > This is a bit unclear.  Presumably you're talking about definiteness of
> > > the outcome (as in what's seen after multiple stores to the same
> > > variable).
> > 
> > No, the last conditions refers to adjacent byte stores from different
> > cpu contexts (either interrupt or SMP).
> > 
> > > The guarantees are only for natural width on Parisc as well,
> > > so you would get a mess if you did byte stores to adjacent memory
> > > locations.
> > 
> > For a simple test like:
> > 
> > struct x {
> > 	long a;
> > 	char b;
> > 	char c;
> > 	char d;
> > 	char e;
> > };
> > 
> > void store_bc(struct x *p) {
> > 	p->b = 1;
> > 	p->c = 2;
> > }
> > 
> > on parisc, gcc generates separate byte stores
> > 
> > void store_bc(struct x *p) {
> >    0:	34 1c 00 02 	ldi 1,ret0
> >    4:	0f 5c 12 08 	stb ret0,4(r26)
> >    8:	34 1c 00 04 	ldi 2,ret0
> >    c:	e8 40 c0 00 	bv r0(rp)
> >   10:	0f 5c 12 0a 	stb ret0,5(r26)
> > 
> > which appears to confirm that on parisc adjacent byte data
> > is safe from corruption by concurrent cpu updates; that is,
> > 
> > CPU 0                | CPU 1
> >                      |
> > p->b = 1             | p->c = 2
> >                      |
> > 
> > will result in p->b == 1 && p->c == 2 (assume both values
> > were 0 before the call to store_bc()).
> 
> What Peter said.  I would ask for suggestions for better wording, but
> I would much rather be able to say that single-byte reads and writes
> are atomic and that aligned-short reads and writes are also atomic.
> 
> Thus far, it looks like we lose only very old Alpha systems, so unless
> I hear otherwise, I update my patch to outlaw these very old systems.

This isn't universally true according to the architecture manual.  The
PARISC CPU can make byte to long word stores atomic against the memory
bus but not against the I/O bus for instance.  Atomicity is a property
of the underlying substrate, not of the CPU.  Implying that atomicity is
a CPU property is incorrect.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/