From: "Saved by Windows Internet Explorer 8" Subject: WG14 N1394 Analyzability Date: Sun, 27 Sep 2009 18:36:32 -1000 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://wiki.dinkumware.com/twiki/pub/WG14/CriticalUndefinedBehavior/n1394-Plum-Seacord-analyzable.html X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
Thomas Plum, tplum@plumhall.com
Robert Seacord, rcs@cert.org
Please refer to WG14/N1350 [N1350= ] for=20 prior context which will not be re-stated here. At Markham, the = Bounds-Checking=20 Library (BCL) was adopted as a separate conditionally-normative annex. = This=20 paper addresses the issues not included in that BCL annex. The minutes = [N1380= ]=20 record the discussion and the votes:
[Begin quotation from N1380]
4.6 Proposal for an Annex to C1X (N1350) (Plum)
N1350 is a proposal to add an annex to C1X that addresses issues that =
have=20
come out of the work of SC22/WG23, Programming Language Vulnerabilities. =
There=20
are four proposals in the paper:
1. Add two definitions to the main =
body of=20
C1X (trap representation, to perform a trap).
2. Add an informative =
Annex to=20
C1X for solutions to various C vulnerabilities.
3. Add four =
definitions to=20
the new annex
- to perform a trap
- out-of-bounds-store
- =
bounded=20
undefined behavior
- critical undefined behavior
4. Add the =
contents of=20
TR24731-1 to the new annex.
[Discussion]
Proposal #4
Focus initially is #4, as an =
informative new=20
annex. Should we do at least this much? Tom would like to see this as a=20
conditionally normative annex, i.e. if you support this, do it this way, =
however=20
support is optional. There has been some NB feedback to not impose a lot =
of new=20
requirements in C1X. David K believes it should be merged in-line.
Lots of discussion, but general support for a = conditionally=81]normative annex.=20 Tom considers such a friendly amendment.
Straw Poll: Support for adding TR24731-1 as a conditionally normative =
Annex=20
to C1X.
Yes - 16
No - 2
Abs - 0
DECISION: Add TR 24731-1 as =
a=20
conditionally normative Annex to C1X.
Proposal #1
Adds the following new definitions for terms that are =
not=20
defined in the definitions, or for terms that are defined in-line in the =
Standard, but not in the definitions.
to perform a trap
Do these definitions conflict with the ISO Vocabulary =
standard?
ACTION:=20
Tom Plum to check that the proposed definitions in N1350 do not conflict =
with=20
the ISO Vocabulary standard. [TP - later confirmed, no conflict]
We do not want to constrain what implementations do when a trap = occurs.=20
Straw Poll: Adopt definitions for 'trap representation' and 'to =
perform a=20
trap' in N1350 to C1X.
Yes =81- 15
No =81- 1
Abs - =
3
DECISION: Adopt=20
definitions for 'trap representation' and 'to perform a trap' in =
Proposal #1,=20
N1350 to C1X.
[Tues - PM]
Proposal #2: Add an informative annex to C1x for =
solutions to=20
various C vulnerabilities (called "Annex K" in this paper), with a =
tentative=20
title such as "Analyzability".
Proposal #3: Provides a number of definitions, and a table of = undefined=20 behavior reclassified (elevated) as critical undefined behavior:=20
N.1 to perform a trap
As defined at 3.17.5, "to perform a trap" =
means to=20
interrupt execution of the program such that no further operations are=20
performed. However, in this Annex K, this interruption is permitted to =
take=20
place by invoking a runtime-constraint handler. Any such semantics are=20
implementation-defined.
N.2 out-of-bounds store
an (attempted) access (3.4.1) which, at =
run-time,=20
for a given computational state, would modify one or more bytes (or for =
an=20
object declared volatile, would fetch one or more bytes) that lie =
outside the=20
bounds permitted by the standard
N.3 bounded undefined behavior
behavior, upon use of a nonportable =
or=20
erroneous program construct or of erroneous data, for which this =
International=20
Standard imposes no requirements, except that the behavior shall not =
perform an=20
out-of-bounds store, and that all values produced or stored are =
indeterminate=20
values.
NOTE The behavior might perform a trap.
N.4 critical undefined behavior
behavior, upon use of a =
nonportable or=20
erroneous program construct or of erroneous data, for which this =
International=20
Standard imposes no requirements
NOTE the behavior might perform an=20
out-of-bounds store, or might perform a trap
All undefined behaviors defined in clauses 1 through 7 of this = International=20 Standard are (in this Annex K) restricted to the semantics of bounded = undefined=20 behavior, except for the following critical undefined behaviors:=20
6.2.4 An object is referred to outside of its lifetime
6.3.2.1 An =
lvalue=20
does not designate an object when evaluated
6.5.3.2 The operand of =
the unary=20
* operator has an invalid value
6.5.6 Addition or subtraction of a =
pointer=20
into, or just beyond, an array object and an integer type produces a =
result that=20
points just beyond the array object and is used as the operand of a =
unary *=20
operator that is evaluated
7.20.3 The value of a pointer that refers =
to space=20
deallocated by a call to the free or realloc function is used
7.21.1, =
7.24.4=20
A string or wide string utility function is instructed to access an =
array beyond=20
the end of an object
PJ: Trouble enumerating between things that are bad with everything =
that is=20
really bad. Believes there should be additional Undefined Behavior on =
this=20
list.
Clark: This is really a basis for work to improve the =
reliability of=20
software.
Tom: This work came from the work OWGV / WG23, and is =
directly=20
applicable to C. The belief is that WG14 is the correct group to vet =
this=20
material.
PJ: Does not believe it belongs in the C Standard, even as =
an=20
informative annex. It's an interesting work in progress.
Straw Poll: Adopt proposals #2 and #3 in N1350 to C1X.
Yes - =
9
No =81-=20
10
Abs - 3
No consensus to add this to the Standard at this =
time
Tom plans to bring this to the next meeting, and try to convince the=20 committee to adopt it. There are other forms this work can take, TR, = position=20 paper, but additional work is needed. Randy: This is still in a fairly = rough=20 state, but in some sense there is still a lot of work to be done. The = problem=20 should continue to be addressed.
[End of quotation from N1380]=20
We propose to add a C1x annex defining compiler restrictions to = assist with=20 implementation of solutions to the problems defined in N1350.=20
The actual title for the annex might be one of the last decisions to = be made:=20 let's first agree on the contents, and then we can pick the title. The = word=20 "vulnerability" is a negative word that defines the problem; presumably = we want=20 a positive word that characterizes some aspects of the solution. For = now, we=20 suggest "Analyzability", because there seemed to be general agreement at = Milpitas that the ability to analyze the C source was essential to all = the=20 audiences listed by WG23. An implementation is operating in "analyzable = mode" if=20 it implements the features described in this Analyzability Annex. For = now, we=20 propose that the annex be conditionally normative. Other categories are=20 possible, but let's first determine the contents and then we can = consider the=20 appropriate category.
There was some discussion not recorded in the Markham minutes, but we = recall=20 some suggestions from Tydeman and Plauger. Tydeman observed that the = standard=20 explicitly calls out bad arguments to library functions as an undefined=20 behavior. That is correct, and even if those library functions are not=20 implemented in C, those arguments could cause an out-of-bounds store. = Plauger=20 observed that calling an incompatible-type function via = pointer-to-function=20 might cause out-of-bounds store as a direct result. We agree with both=20 observations, and have added the corresponding undefined-behavior = citations to=20 the table below.
Add an conditionally normative annex to C1x for solutions to various = C=20 vulnerabilities, with a tentative title such as "Analyzability".=20
Provide the following definitions in the Analyzability Annex:=20
N.1 to perform a trap
As defined at 3.17.5, "to perform a =
trap"=20
means to interrupt execution of the program such that no further =
operations are=20
performed. However, in this Annex, this interruption is permitted to =
take place=20
by invoking a runtime-constraint handler. Any such semantics are=20
implementation-defined.=20
N.2 out-of-bounds store
an (attempted) access (3.4.1) =
which, at=20
run-time, for a given computational state, would modify one or more =
bytes (or=20
for an object declared volatile, would fetch one or more bytes) that lie =
outside=20
the bounds permitted by the standard=20
N.3 bounded undefined behavior
behavior, upon use of a =
nonportable=20
or erroneous program construct or of erroneous data, for which this=20
International Standard imposes no requirements, except that the behavior =
shall=20
not perform an out-of-bounds store, and that all values produced or =
stored are=20
indeterminate values.
NOTE The behavior might perform a trap.=20
N.4 critical undefined behavior
behavior, upon use of a =
nonportable=20
or erroneous program construct or of erroneous data, for which this=20
International Standard imposes no requirements
NOTE the behavior =
might=20
perform an out-of-bounds store, or might perform a trap=20
All undefined behaviors defined in clauses 1 through 7 of this = International=20 Standard are (in this Annex) restricted to the semantics of bounded = undefined=20 behavior, except for the following critical undefined behaviors:=20
6.2.4 | An object is referred to outside of its lifetime = |
6.3.2.1 | An lvalue does not designate an object when evaluated = |
6.5.3.2 | The operand of the unary * operator has an invalid value = |
6.5.6 | Addition or subtraction of a pointer into, or just = beyond, an=20 array object and an integer type produces a result that points = just beyond=20 the array object and is used as the operand of a unary * operator = that is=20 evaluated |
7.20.3 | The value of a pointer that refers to space deallocated = by a=20 call to the free or realloc function is used |
7.21.1, 7.24.4 | A string or wide string utility function is instructed to = access an array beyond the end of an object |
6.3.2.3 | A pointer is used to call a function whose type is not=20 compatible with the pointed-to type |
7.1.4 | An argument to a library function has an invalid value or = a=20 type not expected by a function with variable number of arguments=20 |