I read about Pixel 9 Dolby Decoder bug, and it is based on integer overflow. It was a mistake to allow "+" operator to overflow, and this must be fixed in new languages like Rust, but it is not.

▲ tialaramex 5 hours ago | parent | next [-]

In Rust the decision about whether to pay for overflow checks or just wrap (because all modern hardware will just wrap if you don't check and that's cheaper) is a choice you can make when compiling software, by default you get checks except in release builds but you can choose checks everywhere, even in release builds or no checks even in debug.

By definition in Rust it's incorrect to overflow the non-overflowing integer types, and so if you intend say wrapping you should use the explicit wrapping operations such as wrapping_add or the Wrapping<T> types in which the default operators do wrap - but if you turn off checks then it's still safe to be wrong, just as if you'd call the wrapping operations by hand instead of using the non-wrapping operations.

That Dolby overflow code looks awkward enough that I can't imagine writing it in Rust even if the checking was off - but I wasn't there. However the reason it's on Project Zero is that it resulted in a bounds miss, and that Rust would have prevented anyway.

▲

codedokode 4 hours ago | parent | next [-]

> is a choice you can make when compiling software

That is not a solution because it means the code can behave differently, and expose vulnerability if wrong compilation settings are chosen.

The functions like "wrapping_add" have such a long names so that nobody wants to use them and they make the code ugly. Instead, "+" should be used for addition with exceptions, and something like "wrap+" or "<+>" or "[+]" used for wrapping addition.

That's how people work, they will choose the laziest path (the simplest function name) and this is why you should use "+" for safer, non-wrapping addition and make the symbol for wrapping addition long and unattractive. Make writing unsafe code harder. This is just basic psychology.

C has the same problem, they have functions checking for overflow, but they also have long and ugly names that discourage their use.

> modern hardware will just wrap if you don't check and that's cheaper

So you suggest that because x86 is a poorly designed architecture, we should adapt programing languages to its poor design? x86 will be gone sooner or later anyway.

Also, there are languages like JS, Python, Swift which chose the right path, it is only C and Rust developers who seem to be backwards.

▲

Asmod4n 5 hours ago | parent | prev [-]

__builtin_add_overflow Exists and it’s basically free on most CPUs out there.

	▲	tialaramex 4 hours ago \| parent [-]
		> __builtin_add_overflow Exists and it’s basically free on most CPUs out there. This is a very C-flavoured "solution". For those who haven't seen it this involves a pointer (!) and we're going to compute the addition, write the result to the pointed-at integer and then if that didn't fit and so it overflowed we'll return true otherwise false. The closest Rust analogy would be T::carrying_add which returns a pair to achieve a similar result. And yeah, checking is "basically free" unless it isn't, that's not different. If you haven't measured you don't know, same in every programming language. It's never been true that you can't write correct software in C or C++ the problem is that in practice you won't do so.

▲ jerf 6 hours ago | parent | prev | next [-]

I've been using this as a touchstone for whether or not we are actually going to take security seriously for a long time.

We've moved slightly closer to this, but in a world where we're still arguing over memory safety being necessary we've probably still got a ways to go before we notice that addition silently overflowing is a top-10 security issue. It's the silent top-10 security issue, I guess.

	▲	fyrn_ 5 hours ago \| parent [-]
		Isn't it often combined with poor bounds checks to be exploitable? It's not as if rust or VM based languages don't help a lot with this

▲ IshKebab 5 hours ago | parent | prev [-]

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark.

That said you can enable overflow checks in Rust's release mode. It's literally two lines:

  [profile.release]
  overflow-checks = true

I wonder if it would make sense for ISAs to have trapping versions of add and subtract. RISC-V's justification for not doing that is that it's only a couple more instructions to check afterwards. It would be interesting to see the performance difference of `overflow-check = true` on high performance RISC-V chips once they are available.

	▲	codedokode 3 hours ago \| parent \| next [-]
		I think it is 3 extra instructions on RISC-V if you add signed numbers. So 1 addition (the most popular operation) turns into 4 instructions. What are those people thinking? I generally like RISC-V but this part in my opinion, is wrong. They should just have added "overflow enabled" bit to the add instruction.
	▲	tialaramex 5 hours ago \| parent \| prev \| next [-]
		It does seem like "What if we offer checked integer arithmetic operations?" is a cheaper experiment than CHERI's "What if we mechanically reify extent based provenance"?"
	▲	kps 4 hours ago \| parent \| prev [-]
		> It isn't because no ISA implements add like that MIPS does (did?). And VAX, IBM/360, ....