linux-kernel - Re: Is gcc thread-unsafe?

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, 2 Nov 2007 15:38:09 +0000
From:	Andrew Haley <aph@...hat.com>
To:	"Bart Van Assche" <bart.vanassche@...il.com>
Cc:	"David Schwartz" <davids@...master.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Tomash Brechko" <tomash.brechko@...il.com>
Subject: Re: Is gcc thread-unsafe?

Bart Van Assche writes:
 > On 10/30/07, Andrew Haley <aph@...hat.com> wrote:
 > > David Schwartz writes:
 > > >
 > > > Can we get some kind of consensus that 'optimizations' that add
 > > > writes to any object that the programmer might have taken the
 > > > address of are invalid on any platform that supports memory
 > > > protection?
 > >
 > > That's what the proposed standard language says, kinda-sorta.  There's
 > > an informal description at
 > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html.
 > 
 > There is other important information in the cited text. A.o. it is
 > explained that register promotion of potentially shared variables
 > can introduce data races. Or: register promotion can introduce bugs
 > in multithreaded software when compiled with optimization
 > enabled. Are there any register promotion transformations
 > implemented in gcc that can introduce data races in multithreaded
 > software ?

I expect so.  We're going to have to audit this whole enormous code
base to find them all and take them out.

Note that some of these optimizations have been around since gcc 3.4.

 > This is very important information both for kernel developers and
 > for developers of multithreaded userspace applications.

 > Another conclusion from the cited text is that in contrast with
 > what was stated before on the gcc mailing list, it is not required
 > to declare thread-shared variables volatile if that thread-shared
 > data is consistently protected by calls to locking functions.

Well, let's be clear: ISO 9899:1999 doesn't say so, but the proposed
standard language does.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
-
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/