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:

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.

TR 24731-1 was put together as an approach to retrofit existing = code, and=20 considered by some as not the optimal approach for new code. Hence we = started=20 TR24734-2, which has been through DTR ballot, and for which we are = waiting final=20 text. If we put too much in the Standard. we dilute the entire Standard. = Complex=20 is a likely example.

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.

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]

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.

Avoiding Vulnerabilities

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.

PROPOSAL #1:

Add an conditionally normative annex to C1x for solutions to various = C=20 vulnerabilities, with a tentative title such as "Analyzability".=20

[End of Proposal #1]

PROPOSAL #2:

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

[End of Proposal #2]

References

[N1350] =93Analyzability", ISO/IEC JTC 1/SC 22/WG14 = N1350. http:/= /www.open-std.org/jtc1/sc22/wg14/www/docs/n1350.htm=20

[N1380] "ISO/JTC1/SC22/WG14 AND INCITS PL22.11 SEPTEMBER 2008 = MEETING=20 MINUTES (DRAFT)", ISO/IEC JTC 1/SC 22/WG14 N1380. http:/= /www.open-std.org/jtc1/sc22/wg14/www/docs/n1380.pdf=20

ISO/IEC JTC 1/SC 22/WG14/N1394 - Analyzability