7 ms·

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).

ok123456 4y ago
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory
- pcwalton 4y ago
  You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++. Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569...: "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." In C++ this would never have been filed, because it didn't actually cause any problems. It was only filed for Rust because Rust has much higher standards around even the possibility of potential memory safety problems than C++ does.
  - davidatbu 4y ago
    To add to that, I think the vulnerability is actually caused by unsafe code too: https://github.com/chris-morgan/mopa/issues/13 https://github.com/chris-morgan/mopa/issues/13
- davidatbu 4y ago
  Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any of the above support your claim that "the borrow checker only prevents the easiest memory errors". I imagine one could argue that OOM vulnerabilities are less likely to happen in Zig because of its emphasis on fallible and explicit allocation, but that's still not an argument for the borrow checker only preventing the easiest memory errors I think.
  - dundarious 4y ago
    The original claim was: > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perfectly accurate to say "the borrow checker doesn't stop most memory errors" since you must turn it off when you write the code responsible for "most memory errors" -- at least that is the case in my experience. So in this type of discussion, consider arguments about the capabilities of "the borrow checker" as analogous to arguments about "the memory safety of Rust in general", rather than taking it so literally. If you want to make a sensible argument on this front, it should be about unsafe belonging mostly in crates that have been thoroughly looked over and battle-tested by the community. That is after all, a major reason why the number of such errors is still impressively small. But unsafe errors are still Rust errors, and while the borrow checker is wonderful, it and Rust should still be held accountable for problems in necessary code that requires disabling the borrow checker. I think Zig does pretty well on this front, with there being pros and cons to not having a clearly demarcated "unsafe" boundary built into the language. Lacking an unsafe keyword does make it more unsafe, but in my experience, not very much.
    - Ar-Curunir 4y ago
      I maintain Rust cryptography libraries with over 30-40k LoC, and I have never resorted to unsafe to bypass borrowck. Our code is as performant as any C impl, without the memory safety bugs. There are many such libraries in Rust.
      - dundarious 4y ago
        I wouldn't expect cryptography to need much unsafe. I've never worked in the area, but I expect code mostly falls into 3 domains: parsing, "business" logic (negotiating algorithms, checking certificates/signatures the right way, etc.), and actual crypto algorithms. I see great benefit for Rust in the first two domains. In the algo domain, I don't see how memory safety adds anything as memory issues are an insignificant problem. And there are big challenges like sometimes needing constant-time impls, etc., and how to do that without always having to dip down to hand-written assembly for each target platform. No language I know of provides help in getting bitslicing right, for example. Again, Rust is great for an awful lot of code, but we should still assess Rust's memory safety claims against the data structures code where you often need to disable the borrow checker. An awful lot of people only use safe wrappers around well-tested unsafe code, which is great, but the unsafe code is still being executed and may still have memory "unsafe"ty.

ok123456 4y ago

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory

pcwalton 4y ago
You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++. Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569...: "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." In C++ this would never have been filed, because it didn't actually cause any problems. It was only filed for Rust because Rust has much higher standards around even the possibility of potential memory safety problems than C++ does.
- davidatbu 4y ago
  To add to that, I think the vulnerability is actually caused by unsafe code too: https://github.com/chris-morgan/mopa/issues/13 https://github.com/chris-morgan/mopa/issues/13
davidatbu 4y ago
Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any of the above support your claim that "the borrow checker only prevents the easiest memory errors". I imagine one could argue that OOM vulnerabilities are less likely to happen in Zig because of its emphasis on fallible and explicit allocation, but that's still not an argument for the borrow checker only preventing the easiest memory errors I think.
- dundarious 4y ago
  The original claim was: > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perfectly accurate to say "the borrow checker doesn't stop most memory errors" since you must turn it off when you write the code responsible for "most memory errors" -- at least that is the case in my experience. So in this type of discussion, consider arguments about the capabilities of "the borrow checker" as analogous to arguments about "the memory safety of Rust in general", rather than taking it so literally. If you want to make a sensible argument on this front, it should be about unsafe belonging mostly in crates that have been thoroughly looked over and battle-tested by the community. That is after all, a major reason why the number of such errors is still impressively small. But unsafe errors are still Rust errors, and while the borrow checker is wonderful, it and Rust should still be held accountable for problems in necessary code that requires disabling the borrow checker. I think Zig does pretty well on this front, with there being pros and cons to not having a clearly demarcated "unsafe" boundary built into the language. Lacking an unsafe keyword does make it more unsafe, but in my experience, not very much.
  - Ar-Curunir 4y ago
    I maintain Rust cryptography libraries with over 30-40k LoC, and I have never resorted to unsafe to bypass borrowck. Our code is as performant as any C impl, without the memory safety bugs. There are many such libraries in Rust.
    - dundarious 4y ago
      I wouldn't expect cryptography to need much unsafe. I've never worked in the area, but I expect code mostly falls into 3 domains: parsing, "business" logic (negotiating algorithms, checking certificates/signatures the right way, etc.), and actual crypto algorithms. I see great benefit for Rust in the first two domains. In the algo domain, I don't see how memory safety adds anything as memory issues are an insignificant problem. And there are big challenges like sometimes needing constant-time impls, etc., and how to do that without always having to dip down to hand-written assembly for each target platform. No language I know of provides help in getting bitslicing right, for example. Again, Rust is great for an awful lot of code, but we should still assess Rust's memory safety claims against the data structures code where you often need to disable the borrow checker. An awful lot of people only use safe wrappers around well-tested unsafe code, which is great, but the unsafe code is still being executed and may still have memory "unsafe"ty.