There's no "revelation" here, it's always been well known among experts that Go is not fully memory safe for concurrent code, same for previous versions of Swift. OP has simply spelled out the argument clearly and made it easier to understand for average developers.

▲

tptacek 4 days ago | parent [-]

It's made what would be a valid point using misleading terminology and framing that suggests these are security issues, which they simply are not.

"One could easily turn this example into a function that casts an integer to a pointer, and then cause arbitrary memory corruption."

No, one couldn't! One has contrived a program that hardcodes precisely the condition one wants to achieve. In doing so, one hasn't even demonstrated even one of the two predicates for a memory corruption vulnerability (attacker control of the data, and attacker ability to place controlled data somewhere advantageous to the attacker).

What the author is doing is demonstrating correctness advantages of Rust using inappropriate security framing.

▲

zozbot234 4 days ago | parent [-]

> misleading terminology and framing that suggests these are security issues

Could you quote where exactly OP has misleadingly "suggested" that these concerns lead to security issues in the typical case?

> attacker control of the data, and attacker ability to place controlled data somewhere advantageous to the attacker

Under this definition the Rowhammer problem with hardware DRAM does not qualify as a genuine security concern since it inherently relies on fiddly non-determinism that cannot possibly be "controlled" by any attacker. (The problem with possible torn writes in concurrent Go code is quite similar in spirit; it's understood that an actually observed torn write might only occur rarely.) Needless to say there is a fairly strong case for addressing these problems anyway, as a matter of defence in depth.

> correctness advantages of Rust

Memory safety in OP's sense is not exclusive to Rust. Swift has it. Even Java/C# cannot access arbitrary memory as a result of torn writes. It would be more accurate to say that OP has identified a correctness issue that's apparently exclusive to Go.

▲

tptacek 4 days ago | parent [-]

I quoted directly from the article.

▲

zozbot234 4 days ago | parent [-]

To use your definition, that quote is clearly making a point about correctness, not necessarily about real-world security.

	▲	tptacek 4 days ago \| parent [-]
		As long as we agree that there isn't a meaningful security implication, we don't need to keep litigating.