linux-kernel - Re: [PATCH] "volatile considered harmful", take 3

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-next>] [day] [month] [year] [list]

Message-Id: <E1Hn1VO-0001Gp-Ka@be1.lrz>
Date:	Sun, 13 May 2007 02:00:06 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Satyam Sharma <satyam.sharma@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Johannes Stezenbach <js@...uxtv.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Heikki Orsila <shdl@...alwe.fi>,
	jimmy bahuleyan <knight.camelot@...il.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: [PATCH] "volatile considered harmful", take 3

Satyam Sharma <satyam.sharma@...il.com> wrote:

> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
                                                   ^^^^^^^^^^^^^^
> doesn't, so what are we).
  ^^^^^^^
It does:

ISO/IEC 9899:1999 (E)

5.1.2.3 Program execution

5 The least requirements on a conforming implementation are:
 At sequence points, volatile objects are stable in the sense that previous
 accesses are complete and subsequent accesses have not yet occurred.

9 Alternatively, an implementation might perform various optimizations
 within each translation unit, such that the actual semantics would agree
 with the abstract semantics only when making function calls across
 translation unit boundaries. In such an implementation, at the time of each
 function entry and function return where the calling function and the
 called function are in different translation units, the values of all
 externally linked objects and of all objects accessible via pointers
 therein would agree with the abstract semantics. Furthermore, at the time
 of each such function entry the values of the parameters of the called
 function and of all objects accessible via pointers therein would agree
 with the abstract semantics. In this type of implementation, objects
 referred to by interrupt service routines activated by the signal function
 would require explicit specification of volatile storage, as well as other
 implementation-defined restrictions.

6.7.3 Type qualifiers

6 An object that has volatile-qualified type may be modified in ways unknown
 to the implementation or have other unknown side effects. Therefore any
 expression referring to such an object shall be evaluated strictly according
 to the rules of the abstract machine, as described in 5.1.2.3. Furthermore,
 at every sequence point the value last stored in the object shall agree with
 that prescribed by the abstract machine, except as modified by the unknown
 factors mentioned previously.114) What constitutes an access to an object
 that has volatile-qualified type is implementation-defined.

<snip>

It does not guarantee ordering or consistency beyond the scope of the
assembler layer, especially the CPU or other hardware may be free to cache
or reorder load/stores to these volatile objects (see e.g. MTRR), which is
why you'll usurally want to use something completely different. If you know
an object to not be modified from outside the scope of the C state machine
and it does not have relevant side effects, you can however use volatile
(likely on an atomic value).

I think you should say something like:

1) Don't use volatile
2) Read memory-barriers.txt carefully!
3) If you still use volatile, explain
  a) Why it's nescensary
  b) Why it's enough (see (2))
 to specify volatile on that object. Be sure to consider hardware cache and
 reordering, as well as prohibited optimizations on volatile access and on
 functions possibly doing volatile access.
-- 
Top 100 things you don't want the sysadmin to say:
14. Any more trouble from you and your account gets moved to the 750

Friß, Spammer: rg@...MYD.7eggert.dyndns.org vrl1v@...7eggert.dyndns.org
-
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/