Memory safety is a big deal because many of the CVEs against C programs are memory safety bugs. Thread safety is not a major source of CVEs against Go programs.

It’s a nice theoretical argument but doesn’t hold up in practice.

▲

nine_k 5 days ago | parent | next [-]

A typical memory safety issue in a C program is likely to generate an RCE. A thread-safety issue that leads to a segfault can likely only lead to a DoS attack, unpleasant but much less dangerous. A race condition can theoretically lead to more powerful attacks, but triggering it should be much harder.

	▲	SkiFire13 5 days ago \| parent [-]
		A thread-safety issue does not always lead to a segfault. Here it did because the address written was 42, but if you somehow manage to obtain the address of some valid value then you could read from that instead, and not cause an immediate segfault. I agree with the sentiment that data races are generally harder to exploit, but it _is possible_ to do.

▲

okanat 5 days ago | parent | prev | next [-]

It depends on what threads can do. Threads share memory with other threads and you can corrupt the data structure to force the other thread to do an unsafe / invalid operation.

It can be as simple as changing the size of a vector from one thread while the other one accesses it. When executed sequentiality, the operations are safe. With concurrency all bets are off. Even with Go. Hence the argument in TFA.

	▲	crawshaw 5 days ago \| parent [-]
		All bets aren’t off, we empirically measure the safety of software based on exploits. C memory handling is most of its exploits. Show me the exploits based on Go parallelism. This issue has been discussed publicly for 10 years yet the exploits have not appeared. That’s why it's a nice theoretical argument but does not hold up in practice.

▲

stouset 5 days ago | parent | prev | next [-]

A CVE is worse, but a threading bug resulting in corrupted data or a crash is still a bug that needs someone to triage, understand, and fix.

	▲	crawshaw 5 days ago \| parent [-]
		But it's not why I stopped writing C programs. It's just a bug and I create and fix a dozen bugs every day. Security is the only argument for memory safety that moves mountains.

▲

kllrnohj 4 days ago | parent | prev [-]

This isn't arguing about exploit risks of the language but simply whether or not it meets the definition of memory safe. Go doesn't satisfy the definition, so it's not memory safe. It's quite black & white here.

Nice strawman though