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:	Thu, 04 Sep 2014 22:47:24 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>,
	paulmck@...ux.vnet.ibm.com
CC:	"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

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()).

Regards,
Peter Hurley


--
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/