3 ms·

> Are C memory-related bugs still such a real problem? I believe so, yes. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-s

> Are C memory-related bugs still such a real problem? I believe so, yes. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... > IIUC, Rust can prevent these kinds of memory vulnerabilities. Yes: if your Rust code has memory errors, there's a bug in an "unsafe" block (~1% of the code in a project of mine, which I think is typical) or in the compiler. > But it cant really present the million of other types of vulnerabilities, such as mis-configuration, wrong logic in the code, races, etc It can prevent data races. It can't prevent all possible race conditions. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html

oconnor663 8y ago
> if your Rust code has memory errors, there's a bug in an "unsafe" block Minor clarification around this part. It's possible for a bug in safe code to break an invariant that some correct unsafe code is relying on, if that safe code has private access to something that the rest of the world doesn't. For example, by changing only safe code inside of Vec, you could introduce a bug that set the wrong capacity. Since all the unsafe code in Vec assumes the capacity is correct, that would break everything and cause tons of UB. Vec is sound, though, because the capacity is a private field, and safe code in the caller can't change it. But it does mean that when we're auditing unsafe blocks, we might also need to audit the safe code in the same module, depending on what invariants the unsafe blocks are assuming.
- glennpratt 8y ago
  I guess that's debatable, your point is that code that should be unsafe might not be, but then that did mean the unsafe code is wrong in a sense. It assumes an invariant that isn't enforced.
  - oconnor663 8y ago
    Some people describe it as unsafe code "infecting" its containing module. This section of the nomicon goes into more detail: https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html

oconnor663 8y ago

> if your Rust code has memory errors, there's a bug in an "unsafe" block Minor clarification around this part. It's possible for a bug in safe code to break an invariant that some correct unsafe code is relying on, if that safe code has private access to something that the rest of the world doesn't. For example, by changing only safe code inside of Vec, you could introduce a bug that set the wrong capacity. Since all the unsafe code in Vec assumes the capacity is correct, that would break everything and cause tons of UB. Vec is sound, though, because the capacity is a private field, and safe code in the caller can't change it. But it does mean that when we're auditing unsafe blocks, we might also need to audit the safe code in the same module, depending on what invariants the unsafe blocks are assuming.

glennpratt 8y ago
I guess that's debatable, your point is that code that should be unsafe might not be, but then that did mean the unsafe code is wrong in a sense. It assumes an invariant that isn't enforced.
- oconnor663 8y ago
  Some people describe it as unsafe code "infecting" its containing module. This section of the nomicon goes into more detail: https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html