6 ms·

Wasn't there substantial controversy over gcc optimizing away certain code that tried to check for integer overflows? Check out this infamous thread: https://g

by pak 11y ago

Wasn't there substantial controversy over gcc optimizing away certain code that tried to check for integer overflows? Check out this infamous thread: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 ...it gets pretty nasty! The takeaway is that although overflow is technically undefined, a lot of security-related code was naively implemented by checking for overflows occurring in the most typical way (wraparound), and this check began to be removed by this sort of optimization. This made some pragmatically minded security folks quite angry, because although such behavior is technically undefined by the spec, it was the most widely used method of defending against overflows, and recognizing that such code was already everywhere in the wild they feared all the vulnerabilities that would be introduced by gcc dropping branches for i > i + proposed_increment.

bluecalm 11y ago
>>The takeaway is that although overflow is technically undefined As they say: technically correct is the best kind of correct. >>This made some pragmatically minded security folks quite angry They sound very entitled to me. The C standard is clear on the issue, it's not some arcane hidden thing, it's just a fundamental behavior of basic types in the language. It's very annoying to read the entitled comments from a person who is clearly in the wrong bashing the GCC crew. >> it was the most widely used method of defending against overflows, and recognizing that such code was already everywhere in the wild they feared all the vulnerabilities that would be introduced by gcc dropping branches for i > i + proposed_increment. As mentioned by maintainers in the thread there is already a flag to catch unsigned overflows. They even mentioned a way to catch those overflows in the code. I want a compiler to be technically correct and do optimizations which are possible as the whole point of writing things in C is for them to be fast and efficient. It's nice that GCC has quite a big repertoire of flags, checks, sanity checks, warnings, sanitizers etc. They are very helpful. Demanding that the core compiler doesn't use the language specs to produce better code is pathetic though. It also didn't "break" any real world things. You just need to use proper compiler flags to compile your non-conforming code if you want a newer version of the compiler. Then thank the hard working compiler maintainers for providing those to you as they could've spent their time on something more fun than fixing shitty code for you. /rant
- userbinator 11y ago
  The C standard is clear on the issue The problem is succinctly summarised by the saying "In theory, there is no difference between theory and practice. In practice, there is." Unfortunately what most programmers think of as "C" is subtly different from how the standard defines it. In other words, perhaps we should fix compilers (and eventually the standard) to match reality instead of the other way around. The standard even states in the section on undefined behaviour that "behaving during translation or program execution in a documented manner characteristic of the environment" --- exactly what C programmers are usually expecting from UB --- is a possible choice.
  - rdc12 11y ago
    Except that different programmers subtly different flavour of C is different from others. For a handful of features it may work but in general I doubt it.
  - to3m 11y ago
    Yes. People are quick to point to the standard when it comes to compilers doing something surprising, and quick to use this as evidence that programmers are silly to expect the expected. But if compilers did exactly what these programmers expect, they could point to the standard just the same... (At least this article provides a good explanation of advantages to be had from being aggressively pedantic about UB. Many by way of evidence just wave their hands and claim people are stupid.)
    - username223 11y ago
      > (At least this article provides a good explanation of advantages to be had from being aggressively pedantic about UB. Many by way of evidence just wave their hands and claim people are stupid.) This. While it doesn't show how much real programs benefit from these UB assumptions (or how many new security bugs are introduced...), at least it has some explanations. Still, you have to ask yourself whether the compiler is a tool to help you do your work, or a perverse, pedantic, and frustrating adversary. The ultimate "UB optimizer" would do its best to find tiny corners of undefined behavior in your program, then replace the whole thing with "exit(0)".
nly 11y ago
GCC has builtins for overflow-detecting arithmetic operations, and has done for a while. These generally compile down to one of the jump instruction flavours on x86. https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
- gpvos 11y ago
  These look very unknown to me. How portable are these? If only GCC has these, I am not going to use them at all.
  - frankzinger 11y ago
    Clang also has them: http://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions http://clang.llvm.org/docs/LanguageExtensions.html#builtin-f..., under the heading "Checked Arithmetic Builtins".
  - cnvogel 11y ago
    You could implement them as static/inline functions for compilers that lack the builtins (using a bunch of comparisons with SHORT_/INT_MAX, ...) , which would be slower but for things explicitly meant as security check, probably worth the cost. I've used them to replace explicit checks for overflow in some DSP related code which tried to implement saturation. The gcc builtins also were much faster than tedious "manual" checks.
- tobias3 11y ago
  Here is how to do integer overflow checks from the same author as the OP in the bug report: https://www.fefe.de/intof.html https://www.fefe.de/intof.html

by pak 11y ago

bluecalm 11y ago

>>The takeaway is that although overflow is technically undefined As they say: technically correct is the best kind of correct. >>This made some pragmatically minded security folks quite angry They sound very entitled to me. The C standard is clear on the issue, it's not some arcane hidden thing, it's just a fundamental behavior of basic types in the language. It's very annoying to read the entitled comments from a person who is clearly in the wrong bashing the GCC crew. >> it was the most widely used method of defending against overflows, and recognizing that such code was already everywhere in the wild they feared all the vulnerabilities that would be introduced by gcc dropping branches for i > i + proposed_increment. As mentioned by maintainers in the thread there is already a flag to catch unsigned overflows. They even mentioned a way to catch those overflows in the code. I want a compiler to be technically correct and do optimizations which are possible as the whole point of writing things in C is for them to be fast and efficient. It's nice that GCC has quite a big repertoire of flags, checks, sanity checks, warnings, sanitizers etc. They are very helpful. Demanding that the core compiler doesn't use the language specs to produce better code is pathetic though. It also didn't "break" any real world things. You just need to use proper compiler flags to compile your non-conforming code if you want a newer version of the compiler. Then thank the hard working compiler maintainers for providing those to you as they could've spent their time on something more fun than fixing shitty code for you. /rant

userbinator 11y ago
The C standard is clear on the issue The problem is succinctly summarised by the saying "In theory, there is no difference between theory and practice. In practice, there is." Unfortunately what most programmers think of as "C" is subtly different from how the standard defines it. In other words, perhaps we should fix compilers (and eventually the standard) to match reality instead of the other way around. The standard even states in the section on undefined behaviour that "behaving during translation or program execution in a documented manner characteristic of the environment" --- exactly what C programmers are usually expecting from UB --- is a possible choice.
- rdc12 11y ago
  Except that different programmers subtly different flavour of C is different from others. For a handful of features it may work but in general I doubt it.
- to3m 11y ago
  Yes. People are quick to point to the standard when it comes to compilers doing something surprising, and quick to use this as evidence that programmers are silly to expect the expected. But if compilers did exactly what these programmers expect, they could point to the standard just the same... (At least this article provides a good explanation of advantages to be had from being aggressively pedantic about UB. Many by way of evidence just wave their hands and claim people are stupid.)
  - username223 11y ago
    > (At least this article provides a good explanation of advantages to be had from being aggressively pedantic about UB. Many by way of evidence just wave their hands and claim people are stupid.) This. While it doesn't show how much real programs benefit from these UB assumptions (or how many new security bugs are introduced...), at least it has some explanations. Still, you have to ask yourself whether the compiler is a tool to help you do your work, or a perverse, pedantic, and frustrating adversary. The ultimate "UB optimizer" would do its best to find tiny corners of undefined behavior in your program, then replace the whole thing with "exit(0)".

nly 11y ago

GCC has builtins for overflow-detecting arithmetic operations, and has done for a while. These generally compile down to one of the jump instruction flavours on x86. https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

gpvos 11y ago
These look very unknown to me. How portable are these? If only GCC has these, I am not going to use them at all.
- frankzinger 11y ago
  Clang also has them: http://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions http://clang.llvm.org/docs/LanguageExtensions.html#builtin-f..., under the heading "Checked Arithmetic Builtins".
- cnvogel 11y ago
  You could implement them as static/inline functions for compilers that lack the builtins (using a bunch of comparisons with SHORT_/INT_MAX, ...) , which would be slower but for things explicitly meant as security check, probably worth the cost. I've used them to replace explicit checks for overflow in some DSP related code which tried to implement saturation. The gcc builtins also were much faster than tedious "manual" checks.
tobias3 11y ago
Here is how to do integer overflow checks from the same author as the OP in the bug report: https://www.fefe.de/intof.html https://www.fefe.de/intof.html