Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“gcc will quietly break nearly half of all the packages that it compiles”

metzdowd.com

Post reply on HN
Print view View original

51–60 of 110 posts

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#51

Post by manawy »

copsarebastards wrote: post #42
andrewflnr wrote: post #41

Earlier quoted context omitted.

I believe the complaint is actually that the compiler makes secure code insecure by removing checks that rely on undefined behavior (which presumably can't be made any other way).

That complaint isn't a valid complaint. If the checks relied on undefined behavior, the code wasn't secure. If you want to rely on the behavior of a specific version of a specific compiler, then you need to define that in your dependencies instead of pretending that you've written general-purpose C code. This isn't even just a GCC problem; compiling the code on a different compiler breaks this too.

Yes, I'm really happy that GCC optimize that code away.

Most of us don't care about security issue too much when using C/C++. We do use it for performance, and use it mostly locally.

GCC is a very versatile code. It's ok that it makes secure code difficult to write because it's not what most of us is doing. Not being completely secure is ok, not being optimized is not.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#53

Post by copsarebastards »

makomk wrote: post #45
copsarebastards wrote: post #28

Earlier quoted context omitted.

> On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. --Charles Babbage The modern version of this seems to be: "Mr. Babbage, I put the…

The problem is that it's often perfectly clear, reasonable code on all the systems it was intended to run on. For example, on all Unix-like systems, pointer arithmetic is simply arithmetic and behaves like it. (C's predecessor didn't even have separate pointer and integer types.) So prior to compiler optimisations, this series of operations is safe and well-behaved on all architectures Linux supports even if a is NUL…

I understand the problem, I'm saying that it's not GCC's problem. If you don't want undefined behavior, don't put undefined behavior in your code. The code you wrote isn't clear or reasonable, because it relies undefined behavior. It's a valid criticism that this code does appear to be straightforward when it isn't, but that's not a criticism of GCC, it's a criticism of ANSI C. If you don't like it, use a better language. C was designed 4 decades ago; and they can't possibly have forseen every problem that we've discovered in that time.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#54

Post by nitrogen »

Dylan16807 wrote: post #49
zzalpha wrote: post #31

Earlier quoted context omitted.

Uhh... The question was "what's an example of undefined behaviour". I gave one, specifically of an example that could realistically break by relying on undefined behaviour. That's it. Simple education. In the context of this post I think that's a good thing because not everyone will understand the topic. You, however, seen to have read some sort of agenda in the question, which I find a little baffling...

But that's not "undefined behavior" either. The post misleads people. Certain things are unspecified. It can call in any order for example. Other things are undefined. If you do them your program is no longer valid at all , and can crash or corrupt.

To reiterate/emphasize this point: "undefined", "unspecified", and a few other related terms are Things in C. They have specific, non-interchangeable, well-defined meanings in the C specifications.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#55

Post by [deleted] »

makomk wrote: post #45
copsarebastards wrote: post #28

Earlier quoted context omitted.

> On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. --Charles Babbage The modern version of this seems to be: "Mr. Babbage, I put the…

The problem is that it's often perfectly clear, reasonable code on all the systems it was intended to run on. For example, on all Unix-like systems, pointer arithmetic is simply arithmetic and behaves like it. (C's predecessor didn't even have separate pointer and integer types.) So prior to compiler optimisations, this series of operations is safe and well-behaved on all architectures Linux supports even if a is NUL…

[deleted]

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#56

Post by makomk »

EdiX wrote: post #50
geofft wrote: post #23

Earlier quoted context omitted.

IMO, it's a little subtler than that. It's not the compiler's fault, it's the language's . Plenty of languages have no undefined behavior that can be written by accident. Go and safe Rust, for instance, have just about no undefined behavior at all, and are both performance-competitive with C. (Go has UB if you cause race conditions, and Rust has UB within `unsafe` blocks analogous to C's UB.) A C compiler, meanwhile,…

Yes, the C language specification is a bit shit, it leaves too much leeway to compilers so that C compiler for broken, niche architectures can be written. However, I disagree with you. All this badness in the C specification did not stop people from writing reasonable C compilers for reasonable architectures for decades. The real problem here is competition. Gcc is in a competition with clang to produce fast code whi…

More specifically, they're competing to produce the fastest code for software that follows the C specification to the letter. That's not necessarily the same as producing the fastest code that actually achieves the intended goal.

For example, if I recall correctly the popular Opus codec overflows signed integers when decoding invalid data, and so long as this can be guaranteed to produce some (possibly implementation-specific) result this is perfectly safe. However, this is technically undefined behaviour - a particularly malevolent optimising C compiler could decide to give the sender of the data arbitrary code execution, because it's allowed to do whatever it likes. This might even make the code run faster, but it'd make decoding Opus correctly and safely slower because the decoder would have to do a bunch of gratuitous overflow checks on operations it could otherwise just let overflow. Fortunately, gcc hasn't reached that level of advanced malevolence yet.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#57

Post by copsarebastards »

manawy wrote: post #51
copsarebastards wrote: post #42

Earlier quoted context omitted.

That complaint isn't a valid complaint. If the checks relied on undefined behavior, the code wasn't secure. If you want to rely on the behavior of a specific version of a specific compiler, then you need to define that in your dependencies instead of pretending that you've written general-purpose C code. This isn't even just a GCC problem; compiling the code on a different compiler breaks this too.

Yes, I'm really happy that GCC optimize that code away. Most of us don't care about security issue too much when using C/C++. We do use it for performance, and use it mostly locally. GCC is a very versatile code. It's ok that it makes secure code difficult to write because it's not what most of us is doing. Not being completely secure is ok, not being optimized is not.

Yeah, I'd go so far as to argue that if you need security, you probably shouldn't be writing C.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#58

Post by nitrogen »

mlvljr wrote: post #32
just_curioussss wrote: post #22

Earlier quoted context omitted.

That is called unspecified behavior not undefined behavior. Major difference.

Not many know (and less people care), funnily :) I have yet to see a thorough (source-to-compiler-intent-to-assembly) comparative description of undefined, unspecified and implementation-defined behaviors, though (not just a somewhat insightful blog, or techno gospel, which the C and C++ standards are).

You could always write one. I recommend the work of John Regehr as a starting reference: http://blog.regehr.org/

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#59

Post by GTP »

tedunangst wrote: post #15
babuskov wrote: post #6

Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"

When has 40% not been nearly half? What is the minimum threshold for a quantity to quality as nearly half?

"Nearly half" is a subjective concept so different people can give different answers if you ask them wich value "nearly half" has. I also think that it strongly depends on the absolute number we are talking about, not only percentage.

Re: “gcc will quietly break nearly half of all the packages that it compiles”

#60

Post by MaulingMonkey »

im3w1l wrote: post #43
RyanZAG wrote: post #37

Earlier quoted context omitted.

Umm wait. Undefined behavior is where the language specification is not 100% precise, and compiler implementations can differ on produced code. Go and Rust only have single implementations. The specification for both are very brief. Are you claiming that a clean box implementation of Go and Rust would always behave identically? I have only one thing to say: I clicked through the Golang spec for 30 seconds and found t…

Undefined behavior has a very specific meaning for C. It doesn't mean "not 100% precise". It means 100% imprecise. The C standard only gives any guarantees on what your program will do if you never invoke UB. If you do, well then it can do literally whatever it wants including deleting all your files.

Literally deleting all your files at that. It's the part of the language that says your compiler is completely justified in allowing you to write that buffer overflow vulnerability that can trample executable memory, which is then used by a malicious attacker to do literally whatever they want, including deleting all your files. Or worse.
Post reply on HN