Better handling of integer wraparound in the kernel

Posted Jan 29, 2024 2:18 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: Better handling of integer wraparound in the kernel by donald.buczek
Parent article: Better handling of integer wraparound in the kernel

With my SRE hat on: I'm very happy with this behavior. I do not like it when serving code crashes at runtime. Often enough, the crash is caused by some malformed query (input), and if there are enough of those queries, they will take down your servers faster than the orchestration layer can bring them up again. Then your load balancer sees that you don't have enough servers in this datacenter (region, cluster, zone, whatever you call it), so it starts spilling to other datacenters, taking their servers down too, and before the pager has even gone off, you're having a full-blown cascade failure.

Are there situations where data integrity might dictate failing rather than producing an incorrect value? Of course, but those are properly handled with checked_add() and friends, not with crashing the entire service. If there is any input that can cause your service to crash, it is an outage waiting to happen.

Better handling of integer wraparound in the kernel

Posted Jan 29, 2024 7:23 UTC (Mon) by donald.buczek (subscriber, #112892) [Link] (1 responses)

I understand your perspective, but others might prioritize safety and accuracy, opting for a fail-safe state during unforeseen circumstances. While checked_add() is indeed appropriate for such cases, the debate was about the language's default behavior in the face of coding errors.

Considering your example, isn't there a concern that your internal or external user might have other requirements and would prefer no data over wrong data? Overlooking unexpected overflows might result in serious incidents like Cloudbleed [1]. As a customer, I'd rather see a temporary service disruption than having to learn that my private data has been silently exposed and spilled into search engine caches.

[1]: https://blog.cloudflare.com/quantifying-the-impact-of-clo...

Better handling of integer wraparound in the kernel

Posted Jan 29, 2024 9:25 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> Considering your example, isn't there a concern that your internal or external user might have other requirements and would prefer no data over wrong data?

This is fine if the program is running on the user's computer. If it is not, then a crash will affect everyone whose requests are being processed by that machine, and in the case of cascade failure, fallout will be wider still. There may be situations where failing rather than producing wrong data is preferred, but it is the responsibility of the programmer to understand that requirement and use checked_add etc. instead of regular arithmetic operators. This is no different to any other functional requirement of a software system - if you write the code wrong, it will not work.

> Overlooking unexpected overflows might result in serious incidents like Cloudbleed [1].

Security is hard. I'm not going to solve the general problem of malicious inputs in an LWN comment, but in general, defensive programming is necessary (not sufficient) to deal with problems of this nature. Most languages do not provide integers that always crash on overflow, so handling overflow correctly is something that serious programmers will find themselves having to deal with on a regular basis regardless. Rust provides the necessary methods for doing this front and center, which is more than you can say for most languages (C is only standardizing the equivalent functions in C23!). If you want stronger guarantees than that, I would suggest rewriting the parser (and perhaps a small part of the parser-adjacent application logic) in wuffs.

Besides, if you allow malicious inputs to cause a crash, you make yourself far more vulnerable to denial of service attacks, which are also a security concern (albeit a less serious one).