3 ms·

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/0

by K0nserv 10mo ago

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

lomase 10mo ago
Does Rust not have race conditions?
- Dylan16807 10mo ago
  When talking about the kind that lead to torn memory writes, no it doesn't have those. To share between threads you need to go through atomics or mutexes or other protection methods.
- steveklabnik 10mo ago
  Rust prevents data races, but not race conditions.
- tekne 10mo ago
  One of Rust's core guarantees is that a race condition in safe code will never cause UB. It might return a nondeterministic result, but that result will be safe and well-typed (for example, if it's a Vec, it will be a valid Vec that will behave as expected and, once you have a unique reference, is guaranteed not to change out from under you).
- lenkite 10mo ago
  Rust has double free concurrency bugs https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-... Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud https://github.com/BurtonQin/lockbud USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks https://www.usenix.org/system/files/atc25-tang.pdf https://www.usenix.org/system/files/atc25-tang.pdf
  - codys 10mo ago
    You've linked to a bug that was unintentional and was fixed. Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed. Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
    - lenkite 10mo ago
      I see, you wish to limit the domain. Do safety issues in the async runtime count ? Or is even "async Rust" out of your criteria ? What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
      - aw1621107 10mo ago
        > What about this one ? "Futurelock in Tokyo" ? Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
        lenkite 10mo ago
        What about these ones ? They are considered memory-safety/soundness issues 'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366 https://github.com/rust-lang/rust/issues/84366 Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818
        aw1621107 10mo ago
        I think this is starting to wander rather far afield from where this thread started... But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.

by K0nserv 10mo ago

lomase 10mo ago

Does Rust not have race conditions?

Dylan16807 10mo ago
When talking about the kind that lead to torn memory writes, no it doesn't have those. To share between threads you need to go through atomics or mutexes or other protection methods.
steveklabnik 10mo ago
Rust prevents data races, but not race conditions.
tekne 10mo ago
One of Rust's core guarantees is that a race condition in safe code will never cause UB. It might return a nondeterministic result, but that result will be safe and well-typed (for example, if it's a Vec, it will be a valid Vec that will behave as expected and, once you have a unique reference, is guaranteed not to change out from under you).
lenkite 10mo ago
Rust has double free concurrency bugs https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-... Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud https://github.com/BurtonQin/lockbud USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks https://www.usenix.org/system/files/atc25-tang.pdf https://www.usenix.org/system/files/atc25-tang.pdf
- codys 10mo ago
  You've linked to a bug that was unintentional and was fixed. Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed. Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
  - lenkite 10mo ago
    I see, you wish to limit the domain. Do safety issues in the async runtime count ? Or is even "async Rust" out of your criteria ? What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
    - aw1621107 10mo ago
      > What about this one ? "Futurelock in Tokyo" ? Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
      - lenkite 10mo ago
        What about these ones ? They are considered memory-safety/soundness issues 'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366 https://github.com/rust-lang/rust/issues/84366 Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818
        aw1621107 10mo ago
        I think this is starting to wander rather far afield from where this thread started... But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.