Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

[NotMine999]

Wrap-around arithmetic has been a standard behaviour for at least 40+ years, likely a lot longer. It is not the problem. The problem is with ignorant people who are incompetent at programming, but want to write kernel code. When they cannot write secure code, but need help from sanitisers not to overrun a buffer or to catch overflows, then they have no business writing kernel code. We did not need these tools 40 years ago, and we now only use them as a quality-of-life feature. What we do not need are people who insist on needing protection from their own mistakes. Incompetent people are the security risk, always have been and always will be, no matter the hardware, software, or methodology.

I totally agree. Kees' proposal is yet another attempt by The Nanny State to infuse itself into our daily lives so that we don't have to care, nor be careful, or even responsible for our own actions, work, or creations.

Linus, while never the gifted diplomat, will always tell us where he stands in very clear words that we do not have to parse. What I heard was this: Programmers should be responsible for understanding how their creations truly work AT ALL LEVELS, including the maths. Seriously, I think Linus is like me in some ways, namely: sick & tired of the "If It Compiles Then SHIP IT !" attitude and then looks derisively upon those who (or down their noses at) expect them to explain how it actually all works.

For those people that need warm fuzzy feelings, soft cuddly hugs, and quiet comforting words whenever anyone speaks to them may I suggest that those weak links crawl back to kiddie garden and continue developing for another few decades.

Look, it's a rough world out there and it doesn't owe you anything, so consider yourselves lucky that Linus is willing to be totally & clearly honest about where he stands; you don't have to parse his words to understand him (unlike those warm fuzzy types out there).

[user556]

Sounds like this is really a signed vs unsigned thing. Put the overflow warning on signed ops but leave unsigned rollover out of it.

[ssokolow]

Maybe I am missing something, but if a kernel engineer uses (a + b < a) instead of the shorter (b < 0), isn't that actually in order to include the possibility of wrap around in the condition?

And so it wouldn't be just "fine", but in the absence of more context, most likely a fully correct and intentional use of the feature guaranteed by the language definition?

One would assume so, but even the best humans are fallible. That's the angle I'm looking at it from. I'm not saying that Cook is right, but I think that, absent the context of the proposed design he's reacting to, Torvalds's statement isn't automatically correct.

[indepe]

In Mr. Torvalds' message, the "if (a + b < a)" was preceded by "unsigned int a, b;". As such, (b < 0) will never be true because both a and b are declared non-negative integers, and the expression (a + b < a) in this context is an explicit check for wraparound. HTH!

So even more clearly then, and quite context-independent. I usually test for wraparound with (a > UINT_MAX - b), and didn't recognize the pattern as such.

[indepe]

One would assume so, but even the best humans are fallible. That's the angle I'm looking at it from. I'm not saying that Cook is right, but I think that, absent the context of the proposed design he's reacting to, Torvalds's statement isn't automatically correct.

Yes, fallible, and I would generally encourage the use of warnings, sanitizers, static analyzers, and so on. However I think Linus is correct to say that the compiler must do further analysis to avoid false positives. Using a lot of warnings is extremely time consuming when there are false positives. C is a language that must remain practical for writing optimized code.

[gottagit]

What I heard was this: Programmers should be responsible for understanding how their creations truly work AT ALL LEVELS.

You realize what you ask is impossible.. Codebases of today do not align with a single human being in scope, scale or time. Even Linus doesn't know what the Kernel does at ALL levels anymore.. The Linux kernel code will long outlive Linus Torvalds or Greg KH's time on this Earth. There is good merit in continuing to improve tools in the name of security or catching mistakes, everyone makes them.. No one person is an island.

[darkonix]

I suspect Linus' response is more from the exasperation of repeatedly seeing the same old suggestions slighly reheated.
Unfortunately unchecked integer over-/under-flows are part of the C language's DNA - as much a feature as a flaw.
Changing the language to deal integer overflows in much the same way as Ada (say) would ultimately mean its not C.
Dealing with array bounds errors would likely require promoting C arrays to a first class type and implementing conformant arrays. The pointer/array equivalence would be lost or at best altered and restricted.
Realistically a new C-with-benefits would require almost all existing C code to be changed or rewritten including most the Linux kernel. Like rewriting the Unix kernel in C++ (Sun tried this last century and failed.)
If you were going to this much trouble you might as well design a modern new kernel/operating system from scratch and code in the safer language of your choice. I might laugh if Oberion were the result.

Not necessarily. Look at Rust support in the kernel which currently is about creating modules in Rust, without changing the kernel itself. As long as interfaces are respected C code doesn't care. And it is a project blessed by Linus.

[ssokolow]

Yes, fallible, and I would generally encourage the use of warnings, sanitizers, static analyzers, and so on. However I think Linus is correct to say that the compiler must do further analysis to avoid false positives. Using a lot of warnings is extremely time consuming when there are false positives. C is a language that must remain practical for writing optimized code.

Definitely. Warning fatigue is worse than no warnings because it'll desensitize people to the more significant ones.

[coder]

You are still only an insecure shit poster on a forum.

Try looking in the mirror, before calling others insecure. Your own insecurity is the main reason you can't refute my posts point-by-point, as that would force you to actually reflect on what I'm saying.

Furthermore, if you really wanted to demonstrate your competence and superiority, you'd be making rational arguments instead of hurling insults at everything and everyone you don't like. Resorting to the discursive tactics of an angry school child paints yourself in a far worse light than anything I could probably say.

[carewolf]

I disagree. Without additional context on what a and b are, we can't say whether it's fine.

"(a+b < a)" on unsigned a and b, is only true when a + b overflow. It is an overflow test! So obviously overflow is expected and explicitly handled, an analyser complaining about a check EXPLICITLY testing for overflow as possibly overflowing IS BROKEN.