Hacker News Reader

Comment by eterevsky | Hacker News Reader

I wonder if this could be avoided by writing the canonical implementations in Rust or better yet in some system with formal verification.

This is such a critical part of the software stack, that we need a more reliable way of validation than just a bunch of people staring at the code written in C.

View on HN

Rust won't help. Sure the compiled code would be bounds-checked, but nobody would notice the bug unless they gave it the crashing input. And then when they reimplemented the code in their non-bounds-checked language then that would reintroduce the bug anyway.

A formal verification implementation would catch it at authoring time, yes.

It seems to be an array out of bounds read/write. Rust does bound checks, so this should be covered.

All languages except for C do bound checks, you don't need a borrow checker for this.

Rust doesn't prevent integer over/underflows.

It helps. In Rust debug builds, integer overflows crash -> tests will detect them. In release builds they're not detected by default, but you can add "overflow-checks = true" to the Cargo profile to enable those checks in release builds too if you want.

overflow-checks=true is already present in many cryptographic and blockchain Cargo packages, as its trade-offs are worth it Vs. a human error.

Additionally the only type allowed for array indexing and buffer slicing is usize, equivalent of size_t, and it's 64-bit on 64-bit platforms.

>In Rust debug builds, integer overflows crash

That's true with C/C++ compilers too, if you want, using UBSan.

Unsigned integer overflow is not undefined behavior in C++ so won't be caught by UBSan.

Also, UBSan is more overhead than turning on Rust's overflow checking.

Yes, but crypto should probably use under/overflow safe arithmetic, which the rust standard library allows for.

Reply on news.ycombinator.com