US-CERT Vulnerability Note VU#162289

[Robert Dewar]

Paul Schlie wrote:
>> Florian Weimer wrote:
>>
>>> Robert C. Seacord wrote:
>>>
>>> i agree that the optimization is allowed by C99.  i think this is a
>>> quality of implementation issue,  and that it would be preferable for
>>> gcc to emphasize security over performance, as might be expected.
>> I don't think this is reasonable.  If you use GCC and its C frontend,
>> you want performance, not security.  After all, the real issue is not
>> the missing comparison instruction, but the fact that this might lead to
>> subsequent unwanted code execution. ...
>>
>> The problem I see with this particular case is that the type of
>> comparison you describe is bogus even if translated to straight machine
>> code because it assumes an awful amount of detail about the target
>> environment. ...
> 
> No, (nor necessarily a question of "security over performance") but
> rather a question of whether any optimization should functionally change
> observable program behavior, which in general it should be clear it never
> should,

Didn't we tread down this path before with someone who had extreme
views on this topic, perhaps it was you Paul, can't remember.

Anyway, the view that optimization can never change observable
behavior is going MUCH too far, if, as seems the case, you are
including programs with undefined behavior. It most likely
would preclude almost ALL optimization, because if you have a
program which references uninitialized variables, then the values
of these variables could be changed by ANY optimization.

At another level, any optimization changes the performance and
timing, and if you consider the length of time as an observable
behavior, then by definition you would preclude all optimization.
It is in any case easy enough to write a program which does totally
different things depending on how long parts of it take to run.

So though I generally am conservative about optimizations that affect
widely expected behavior, I don't for a moment buy this extreme position.


> Aggressive optimizations (particularly those which do not coincide with
> the factual behavior of most targets) should arguably only be invoked
> by explicit request (i.e. not at a generic level of optimization). IMHO.

Ah yes, it *was* you :-)
I remember this bogus attempt to talk about the "factual behavior" of
a target, which seems complete nonsense to me.