5 ms·

Why would you need a static analyzer for a language that promotes itself as safe out of the box.

School-Cotton 4y ago
Rust claims to make a particular class of bugs more difficult to write. It doesn’t claim to magically eliminate all of them.
the-lazy-guy 4y ago
It is written in the linked README, but I will state it here. Rust checks integer overflows at runtime (or not at all, if building for maximum speed). It is safer than not checking at all. But costs performance and can lead to (predictable) crashes. This tool is a way to prove that overflows can not happen at compile time. Which is extremely hard in the general case.
- kibwen 4y ago
  Also note that the reason that Rust can get away with not checking for integer overflow while still being memory-safe is because indexing operations are bounds-checked, so an overflowing index variable panics anyway.
  - cesarb 4y ago
    > so an overflowing index variable panics anyway. Unless it overflows all the way to a valid index. Which might lead to unexpected results if the code does not expect to be using a smaller index (for instance, a code trying to access index i+2 might not be expecting it to suddenly access indexes 0 or 1).
    - iudqnolq 4y ago
      But Rust is still memory safe because unsafe code "morally" is unsound if it assumes something like that can't happen.
naasking 4y ago
> safe out of the box Safe Rust is memory safe and data race safe. There are other forms of safety obviously, like overflow safety, numerous forms of confidentiality and security properties, etc.
pjmlp 4y ago
It is safe for the 70% of security flaws found out in languages like C and C++. The remaining 30% still need to be tracked down.
- Arch-TK 4y ago
  I wonder where you got those numbers from.
  - Vecr 4y ago
    A report about Windows written by Microsoft, I think.
  - davidatbu 4y ago
    Almost every study of security vulnerabilities concludes that roughly 70% of them are caused by memory unsafety.
  - dcsommer 4y ago
    https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/#how-common-are-vulnerabilities-due-to-memory-unsafety https://alexgaynor.net/2019/aug/12/introduction-to-memory-un...
  - mynameisash 4y ago
    From Microsoft[0]: "As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues." And from Google[1]: "memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities." [0] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... [1] https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat...
- IshKebab 4y ago
  I would say at least half of the remaining 30% are eliminated by Rust's stronger type system and borrow checker too. When I'm writing Rust it feels like I write around 10x fewer bugs than in C++.
a_humean 4y ago
Rust promises that safe rust is memory/type safe. You can still get interger over/under-flows, indexing out of bounds, and allocation failures (oom), etc... all of which "panic" - which means that rust will safely unwind the stack and exit in a way that remains memory safe.
jerf 4y ago
In addition to the many other fine points about how Rust doesn't perfectly secure against everything, having a static analyzer out of the compiler means that the static analyzer can continue to develop on its own time frame without being tied to the compiler releases. The importance of this is easy to underestimate. It is really helpful to have external projects able to iterate independently for this sort of thing.
IshKebab 4y ago
This is a fair question really. Calling it a static analyser is misleading and seems to be editorialised. It's not like static analysers in C++. It's actually a formal verification tool. They call it a "static verifier" not a "static analyser". Most static analysis tools seek to find potential problems in your code - generally common mistakes - but they aren't proving anything usually. They have false positives and negatives. Formal verification requires you to write properties about your code and then it proves it.
- burjui 4y ago
  - I am pretty sure that static verifiers are a subclass of static analysers. - Prusti does not require you to write any "properties". I just ran it on a piece of code, which has no annotations for Prusti, and it still found a potential integer overflow. Maybe it has some internal annotations for std, but none for my code.

Rust claims to make a particular class of bugs more difficult to write. It doesn’t claim to magically eliminate all of them.

the-lazy-guy 4y ago

It is written in the linked README, but I will state it here. Rust checks integer overflows at runtime (or not at all, if building for maximum speed). It is safer than not checking at all. But costs performance and can lead to (predictable) crashes. This tool is a way to prove that overflows can not happen at compile time. Which is extremely hard in the general case.

kibwen 4y ago
Also note that the reason that Rust can get away with not checking for integer overflow while still being memory-safe is because indexing operations are bounds-checked, so an overflowing index variable panics anyway.
- cesarb 4y ago
  > so an overflowing index variable panics anyway. Unless it overflows all the way to a valid index. Which might lead to unexpected results if the code does not expect to be using a smaller index (for instance, a code trying to access index i+2 might not be expecting it to suddenly access indexes 0 or 1).
  - iudqnolq 4y ago
    But Rust is still memory safe because unsafe code "morally" is unsound if it assumes something like that can't happen.

naasking 4y ago

> safe out of the box Safe Rust is memory safe and data race safe. There are other forms of safety obviously, like overflow safety, numerous forms of confidentiality and security properties, etc.

pjmlp 4y ago

It is safe for the 70% of security flaws found out in languages like C and C++. The remaining 30% still need to be tracked down.

Arch-TK 4y ago
I wonder where you got those numbers from.
- Vecr 4y ago
  A report about Windows written by Microsoft, I think.
- davidatbu 4y ago
  Almost every study of security vulnerabilities concludes that roughly 70% of them are caused by memory unsafety.
- dcsommer 4y ago
  https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/#how-common-are-vulnerabilities-due-to-memory-unsafety https://alexgaynor.net/2019/aug/12/introduction-to-memory-un...
- mynameisash 4y ago
  From Microsoft[0]: "As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues." And from Google[1]: "memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities." [0] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... [1] https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat...
IshKebab 4y ago
I would say at least half of the remaining 30% are eliminated by Rust's stronger type system and borrow checker too. When I'm writing Rust it feels like I write around 10x fewer bugs than in C++.

a_humean 4y ago

Rust promises that safe rust is memory/type safe. You can still get interger over/under-flows, indexing out of bounds, and allocation failures (oom), etc... all of which "panic" - which means that rust will safely unwind the stack and exit in a way that remains memory safe.

jerf 4y ago

In addition to the many other fine points about how Rust doesn't perfectly secure against everything, having a static analyzer out of the compiler means that the static analyzer can continue to develop on its own time frame without being tied to the compiler releases. The importance of this is easy to underestimate. It is really helpful to have external projects able to iterate independently for this sort of thing.

IshKebab 4y ago

This is a fair question really. Calling it a static analyser is misleading and seems to be editorialised. It's not like static analysers in C++. It's actually a formal verification tool. They call it a "static verifier" not a "static analyser". Most static analysis tools seek to find potential problems in your code - generally common mistakes - but they aren't proving anything usually. They have false positives and negatives. Formal verification requires you to write properties about your code and then it proves it.

burjui 4y ago
- I am pretty sure that static verifiers are a subclass of static analysers. - Prusti does not require you to write any "properties". I just ran it on a piece of code, which has no annotations for Prusti, and it still found a potential integer overflow. Maybe it has some internal annotations for std, but none for my code.