
How MutexGuard Was Sync When It Should Not Have Been - Rusky
https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html
======
andrewflnr
Lots of discussion on /r/rust:
[https://www.reddit.com/r/rust/comments/6gavfe/how_mutexguard...](https://www.reddit.com/r/rust/comments/6gavfe/how_mutexguard_was_sync_when_it_should_not_have/)

------
ishitatsuyuki
Such things can become a vulnerability when Rust becomes popular enough ;)

~~~
pcwalton
Remember that, for these soundness issues to result in vulnerabilities, they
(1) have to be accidentally relied upon in code (2) that can be controlled by
attackers (3) in a way that results in a vulnerability (use after free with
attacker controlled heap, etc).

It's worth comparing to other languages. There are known ways to segfault PHP
and most other scripting languages, but those bugs aren't considered security
problems unless they meet all three criteria above. In Go, there are even
known ways to get use-after-free without using the unsafe package that won't
be fixed by design. That doesn't stop security experts from recommending the
language, because, again, any such UAFs are not likely to meet all these
criteria.

Now in Rust we prioritize soundness issues highly, because we want safe code
to actually be safe. We have high standards for ourselves--our standard is
almost as high as that of runtimes that are intended to execute hostile code,
such as JavaScript engines. Unlike with JS engines, though, fixes to soundness
issues around the edges of Rust are probably not going to have much of a
practical security impact. (The probability of these correctness issues having
security implications is not _zero_ , to be sure, but it's small.) Finding and
fixing these problems mostly serves to keep us honest.

~~~
breakingcups
I'm interested in the use-after-free scenario in Go. Do you have any sources?

~~~
littlestymaar
See Russ Cox's (Go core team) blog post about Go's memory safety & data races
: [https://research.swtch.com/gorace](https://research.swtch.com/gorace)

