[Cryptography] GCC bug 30475 (was Re: bounded pointers in C)

[Arnold Reinhold]

On Apr 29, 2014, at 11:21 PM, Benjamin Kreuter <brk7bx at virginia.edu> wrote:

> On Tue, 2014-04-29 at 19:56 -0400, Arnold Reinhold wrote:
>> The C standards committee, as far as I know, only said that signed
>> integer overflow was undefined. They never required that code which
>> could create such an overflow, and any code dependent on such an
>> operation, be removed.
> 
> Maybe so, but it is also not prohibited to remove it.  

As I pointed out there are a lot of evil thing the compiler could do with undefined code that are not prohibited by the C standards. That does not mean it is ok to do them. There are other standards for human behavior besides those written by programming language committees.

> I would want this
> to be optimized by my compiler:
> 
> if(x > x + 1) { /* ... */ }
> 
> Yet someone might have been using "x > x + 1" as a way to check "x ==
> INT_MAX", and such an optimization would cause a problem for them.

Why would you want the compiler to silently remove that code? If it wasn't an overflow check, maybe you made a typo--when you wrote that line you had something in mind.  Wouldn't it be better for the compiler to flag that statement so you could review it and either correct it or remove if from your source file? Why would you want a nonsense statement to remain in your program? 

> 
>> It is every bit as irresponsible to silently remove safety checks
>> placed in software by programmers who may not have understood all the
>> implications of “undefined” or did not fully grasp the arcane
>> techniques needed to write “legal” safety checks.
> 
> Perhaps a language that requires arcane techniques to write safe code
> should not be used for anything security sensitive.

That horse has left the barn long ago. Thousands of security sensitive programs written in C are in use today. And programmers don't often have the luxury of deciding what language to use. Often security is only a small part of a larger project and the choice of which language to use for a project has been decided for other reasons. Isn't it more reasonable to expect the developers of C to respond to the safety needs of their users and the public?

> 
>> In no context is it acceptable to knowingly remove or defeat someone
>> else’s safety mechanisms without permission, much less without warning.
> 
> How do you know something is a safety check?  What you are really saying
> here is that compilers should never silently optimize undefined
> behavior.  This is probably not possible, so at best you will have a
> compiler that warns about *common* undefined behaviors that are easy to
> detect (which popular compilers already can do).

Well, to begin with Bug 30475 was about an assert statement and these are pretty much always safety checks. I realize that assert is a macro, but in principle there is no reason the compiler can't be aware of this. But not all safety checks are written as asserts. A program abort may not be the safe response to an error. So yes, I am saying  that compilers should never silently optimize undefined behavior. An optimizer is supposed to generate code that produces the same output as the original program, but more efficiently. If a behavior is undefined, how can the optimizer conclude that the output will be the same? I would think undefined behavior is the last thing I would want an optimizer to touch. 

> 
> If optimizers were truly *forbidden* from relying on anything that might
> be undefined behavior in C, almost no good optimization would be
> possible.  It is reasonable and necessary for the optimizer to leave it
> up to the programmer to prevent undefined behavior.

Do you have nay evidence for this claim? How many statements with undefined behavior do you think are in a typical program? How many nanoseconds would we waste if the compiler just left them alone?

Arnold Reinhold