3 ms·

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 critic

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.

Arnavion 4y ago
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.
- ysleepy 4y ago
  It seems to be an array out of bounds read/write. Rust does bound checks, so this should be covered.
  - GoblinSlayer 4y ago
    All languages except for C do bound checks, you don't need a borrow checker for this.
execveat 4y ago
Rust doesn't prevent integer over/underflows.
- roca 4y ago
  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.
  - miohtama 4y ago
    overflow-checks=true is already present in many cryptographic and blockchain Cargo packages, as its trade-offs are worth it Vs. a human error.
  - 1over137 4y ago
    >In Rust debug builds, integer overflows crash That's true with C/C++ compilers too, if you want, using UBSan.
    - roca 4y ago
      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.
  - pornel 4y ago
    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.
- eptcyka 4y ago
  Yes, but crypto should probably use under/overflow safe arithmetic, which the rust standard library allows for.

Arnavion 4y ago

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.

ysleepy 4y ago
It seems to be an array out of bounds read/write. Rust does bound checks, so this should be covered.
- GoblinSlayer 4y ago
  All languages except for C do bound checks, you don't need a borrow checker for this.

execveat 4y ago

Rust doesn't prevent integer over/underflows.

roca 4y ago
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.
- miohtama 4y ago
  overflow-checks=true is already present in many cryptographic and blockchain Cargo packages, as its trade-offs are worth it Vs. a human error.
- 1over137 4y ago
  >In Rust debug builds, integer overflows crash That's true with C/C++ compilers too, if you want, using UBSan.
  - roca 4y ago
    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.
- pornel 4y ago
  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.
eptcyka 4y ago
Yes, but crypto should probably use under/overflow safe arithmetic, which the rust standard library allows for.