This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: US-CERT Vulnerability Note VU#162289


Robert C. Seacord wrote:

Just because a program contains undefined behavior, does not mean that it erroneous. It simply gives the compiler latitude with how to handle the undefined behavior, while still conforming.

Actually, erroneous and undefined are approximately synonymous.


There are various categories of behavior not mandated by the standard. The standard identifies:

* implementation-defined behavior

unspecified behavior where each implementation documents how the choice is made

* unspecified behavior

behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

* undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

And:

Addition or subtraction of a pointer into, or just beyond, an array object and an integer type produces a result that does not point into, or just beyond, the same array object (6.5.6).

is undefined behavior.


This is the same class as using the value of an uninitialized variable, dividing by zero, or any other erroneous construct that cannot be diagnosed at compile-time. From the point of view of the standard, your example of a "secure" program is no more portable than one that reads random uninitialized memory and depends on the result.

That said, the GCC developers have already implemented a warning option to warn about the case where optimizations are made on this basis. I do not know if it is in -Wall or not. I doubt it, because it would probably create far too many false positives.

Declaring that a compiler is "vulnerable" because it performs a valid optimization performed by most of the leading compilers is somewhat odd. Declaring it vulnerable while not declaring those others to be vulnerable is unfair. However, I do appreciate that issues in GCC is probably more important than issues in other compilers, given GCC's overwhelming popularity and the increasing degree to which vitally important software is built with GCC.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]