Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safety

memorysafety.org

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Memory Safety

#71

Post by crawshaw »

saagarjha wrote: post #66
crawshaw wrote: post #6

Earlier quoted context omitted.

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…

Why do you think data races are not a practical source of bugs?

Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.

Re: Memory Safety

#72

Post by AnthonyMouse »

crawshaw wrote: post #6
codys wrote: post #2

This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…

The thing that annoys me more is the singular focus on memory safety as if nothing else matters. For example, by most definitions PHP is a "memory safe" language, but it's also full of poor design choices and the things written in it have a disproportionate number of security vulnerabilities. JavaScript is also classically modeled as a gelatinous mass of smoldering tires and npm seems to have been designed for the purpose of carrying out supply chain attacks.

So then we see an enormous amount of effort being spent to try to replace everything written in C with Rust when that level of effort should have been able to e.g. come up with something which is easy enough for ordinary people to use that it could plausibly displace WordPress but has a better security posture. Or improve the various legacy issues with distribution package managers so that people stop avoiding them even for popular packages in favor of perilous kludges like npm and Docker.

Re: Memory Safety

#73

Post by codys »

woodruffw wrote: post #53
codys wrote: post #2

This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

I think Go is effectively memory safe. The relevant test is for the presence of exploitable memory corruption, and to my understanding that’s never been a real issue with Go.

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer.

Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their definition of memory safe (and this post's website has a definition does as well):

https://research.swtch.com/gorace

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Re: Memory Safety

#74

Post by codys »

llmslave2 wrote: post #15
codys wrote: post #2

This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

Or perhaps because you are using an uncommon definition for "memory safety".

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety.

Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

Re: Memory Safety

#75

Post by saagarjha »

crawshaw wrote: post #71
saagarjha wrote: post #66

Earlier quoted context omitted.

Why do you think data races are not a practical source of bugs?

Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.

No they’re pretty important these days now that basic linear overflows and the like are harder to exploit

Re: Memory Safety

#77

Post by llmslave2 »

codys wrote: post #74
llmslave2 wrote: post #15

Earlier quoted context omitted.

Or perhaps because you are using an uncommon definition for "memory safety".

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety. Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

Has this problem (which is really a race condition problem) ever been shown to be exploitable or lead to issues?

Re: Memory Safety

#78

Post by codys »

llmslave2 wrote: post #77
codys wrote: post #74

Earlier quoted context omitted.

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety. Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

Has this problem (which is really a race condition problem) ever been shown to be exploitable or lead to issues?

It sounds like you have a definition of memory safety you aren't disclosing.

Please fully provide your definition of memory safety. Not interested in trying to figure out what it is in a 20-questions-over-hn way.

Re: Memory Safety

#79

Post by aw1621107 »

codys wrote: post #73
woodruffw wrote: post #53

Earlier quoted context omitted.

I think Go is effectively memory safe. The relevant test is for the presence of exploitable memory corruption, and to my understanding that’s never been a real issue with Go.

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer. Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their defini…

"Effectively" is the key word in GP's comment - i.e., there are no known real-world vulnerabilities in Go code that are attributable to tearing on data races, so the claim is that that particular memory safety flaw does not exist in practice.

Re: Memory Safety

#80

Post by codys »

aw1621107 wrote: post #79
codys wrote: post #73

Earlier quoted context omitted.

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer. Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their defini…

"Effectively" is the key word in GP's comment - i.e., there are no known real-world vulnerabilities in Go code that are attributable to tearing on data races, so the claim is that that particular memory safety flaw does not exist in practice .

Interesting interpretation of that phrase. I think saying "probabilistically memory safe" would be more accurate (and more clearly communicate that idea), because we're betting on when a known case of memory unsafety in the language will show up in some piece of software.
Post reply on HN