Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

[Jakobson]

Linus is not very good at conversational skills.

[ssokolow]

IOW, exactly the same as "a+b < a". Yes, "a+b" might wrap around, but if the use is to then compare it with one of the addends, then clearly such a wrap-around is fine.

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

[sdack]

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.

[EphemeralEft]

“It looks like you’re adding two numbers together. Would you like help?”

[coder]

Just my own hot take, without having extensively studied the issue or worked inside the kernel:

1. Define a function or special operator which indicates that overflow is expected/acceptable. I believe these cases are far more the exception than the norm.
2. For everything else, if the compiler can't ensure, via static analysis, that overflow is impossible, emit a sanitizer to check for it. Someone not wanting the runtime overhead of these sanitizers can either promise the compiler it won't overflow (i.e. via some builtin or attribute) or simply compile without them.

In the overwhelming amount of my userspace code, overflows should never happen. I could easily embrace the above, with virtually no impact on the readability my code or productivity.

[coder]

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.

Okay, so then first you need to figure out how to keep all of those people from getting their changes into the kernel sources. Only once you've worked that out can you truly ignore them and their cognitive limitations.

We did not need these tools 40 years ago,

Oh, right. Because software never had bugs, back then. I must've forgotten.

What we do not need are people who insist on needing protection from their own mistakes.

Given that you hold so many programmers in such a low esteem, it surprises me you're not concerned about your exposure to their mistakes. Unless you're the only one writing the code, it would seem you have a far bigger stake in that than in your own mistakes.

Incompetent people are the security risk, always have been and always will be, no matter the hardware, software, or methodology.

I eagerly await your solution to protect us all from incompetent people that doesn't involve better tooling. I have yet to see such a solution so far...

[indepe]

Unsigned wrap around is part of the language definition, and often taken advantage of when optimizing code. You may have a different opinion about whether that is a good idea, but it may be that you just have little experience with situations where it is used (intentionally).

Maybe it is just me, but lately I see a lot of disregard for false positives in compiler warnings. False positives are a big problem, especially for those who do like to use strict compiler warnings (and maybe also make warnings be errors).

[coder]

unsigned arithmetic being well defined is a no brainer for most devs I hope.

Just because one understands how arithmetic overflows/underflows are handled by the hardware doesn't mean your code is impervious to wraparound bugs.

Unsigned wrap around is part of the language definition, and often taken advantage of when optimizing code.

Nobody is saying wraparounds should be banned. Just that there should be a way to detect/handle unintended wraparounds.

Even in your code, I'm sure it's much more the exception than the rule that you actually expect arithmetic overflows/underflows. When you write such code, you know in your head when you expect that possibility, so why not just be explicit about it?

Maybe it is just me, but lately I see a lot of disregard for false positives in compiler warnings. False positives are a big problem, especially for those who do like to use strict compiler warnings (and maybe also make warnings be errors).

I don't disregard these, which is why (above) I suggested sanitizers instead of warnings. There are too many cases where the code might be fine, but a static analyzer can't be sure. Emitting a runtime check seems like a safe middle-ground and won't hurt performance in the vast majority of cases. Maybe you'd want to explicitly disable these sanitizers, in some performance-critical loops...

[emblemparade]

The practical solution, I think, is not in compilers but in code. It would be very useful to have a library of "safe math" functions that report errors for overflows and wraparounds. Use this library when you're doing arbitrary math with arbitrary values. Linus is right that sometimes overflows are a feature. But ... in many cases they are a bug and even a security risk. A bug that is very common, even for experienced programmers, and one that's hard to test against unless you're specifically testing for it.

I imagine that there are many places in the kernel where arbitrary math happens and that safe math functions would be a boon.

[indepe]

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

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?