7 ms·
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 i
by codys 9mo ago
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.
- websiteapi 9mo agois go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.
- muricula 9mo agoUsually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.
- websiteapi 9mo agois there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?
- Yoric 9mo agoIt's not that race conditions are generally memory-unsafe. The same race conditions would not be memory-unsafe in, say, Java or Python. Go has a memory model that basically guarantees that the language is memory-safe except with a few marked "unsafe" functions or in case of race conditions involving interfaces or arrays. It's pretty easy to come up with an example of such a race condition that will cause reads or writes from/to unpredictable memory addresses. I imagine it's quite feasible to turn this into reads or writes from/to crafted memory addresses, which would be a mean to defeat pretty much any security measure implemented in the language. The Rust community caters to people who are a bit obsessive about safety (including myself) and Rust developers tend to consider this a bug in the design of the Go language (there are a few, albeit much harder to achieve, issues that are vaguely comparable in Rust and they are considered bugs in the current design of Rust). The Go community tends to attract people who are more interested in shipping than in guarantees, and Go developers who are aware of this issue tend not care and assume that this is never going to happen in practice (which may or may not be true, I haven't checked).
- awesome_dude 9mo ago> is there actually a programming language that makes race conditions impossible To my knowledge, no. > if the existence of races makes a language unsafe, then aren't all languages unsafe? Are we talking about "data races" or "race conditions" One can lead to the other, but race conditions are a much bigger set. AIUI It's impossible for any language level controls to prevent any and all race conditions, because some are happening outside of the binary/process/computer. Data races, OTOH are almost trivial to protect against - a contestable thing must have a guard that ensures a writer has exclusive access to that thing for the duration of the write. Some languages do this with mutually exclusive locks (mutex/semaphore/go channels), some languages/paradigms do this by never having shareable objects (Functional Programming/Pass by Value), and some (Rust) are doing this with the compile time checks and firm rules on a single writer. Edit: Never having shareable objects should really be "never allowing an outside thread/coroutine/process/whatever mutate your copy of an object" meaning that an object is immutable to them, and they have to have a copy that they can mutate to their heart's content. They have to communicate any changes back, and then you choose whether to integrate those changes, or not
- i_am_a_peasant 9mo agoisn’t that the point of languages that have first class actor models something something?
- SkiFire13 9mo agoEven in those languages you can easily have the equivalent of race conditions simply due to the order messages are received.
- torginus 9mo ago>is there actually a programming language that makes race conditions impossible It'd be very hard to make something that offers that guarantee in the real world. One of the most common, IRL exploitable race conditions are ones that involve multiple services/databases, and even if your programming language would have such a feature, your production system would not.
- muricula 9mo agoPython has that property when you don't bring C extensions into the conversation. Data races exist, but can never cause memory corruption due to the GIL.
- pjmlp 9mo agoGIL is on its way out already in 3.14 onwards.
- K0nserv 9mo agoChanges 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 9mo agoDoes Rust not have race conditions?
- Dylan16807 9mo agoWhen 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 9mo agoRust prevents data races, but not race conditions.
- tekne 9mo agoOne 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 9mo agoRust 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
- tptacek 9mo agoGo is absolutely memory safe in the sense used by Prossimo and software security. It's not "safe" in an academic sense used by almost nobody except message board language warriors.
- pjmlp 9mo agoUsually it is Rust message board language warriors. Which also overlook how Rust type system can be subverted to actually allow for data races, with some help of linker scripts and OS IPC primitives.
- jkdjfdsnjsdf 9mo agoBy that standard it also incorrectly categorizes rust as memory safe.
- Dylan16807 9mo ago> By that standard What standard?
- crawshaw 9mo agoI 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 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 of thing I have seen again and again in the Rust "community" that I find deeply off-putting. Build good things, do not play snooty word games.
- saagarjha 9mo agoWhy do you think data races are not a practical source of bugs?
- crawshaw 9mo agoData 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.
- saagarjha 9mo agoNo they’re pretty important these days now that basic linear overflows and the like are harder to exploit
- 9mo ago
- AlotOfReading 9mo agoIf we're being extremely strict, Python probably also shouldn't be on that list because the CPython runtime is written in C and has had issues with memory safety in the past. Ultimately, "memory safety" is a conversation about what a program is intended to do and what semantics the language guarantees that program will have when executed. For the vast majority of programs, you can be just as confident that your Go and Python code will do the right things at runtime as your safe Rust. It's good enough.
- vlovich123 9mo agoNo, because then no language would be included, including Rust. Implementation bugs are not treated the same as integral parts of the language as defined by the standard. Python is defined as memory safe.
- AlotOfReading 9mo agoI understand this website as focusing on unsafety in a more practical sense of writing your stack in memory safe ways, not in the sense of discussing what's theoretically possible within the language specs. After all, Fil-C is standard compliant, but "run everything under Fil-C" is not the argument it's making. The most common language runtime being memory unsafe is absolutely an applicable argument here, mitigated only by the fact that it's a mature enough runtime that memory issues are vanishingly rare.
- vlovich123 9mo agoFil-C is super new and while it is memory safe, a lot of work is still ongoing in terms of getting existing programs to run under it and currently it only supports Linux which is nowhere near being “c and C++ can now be memory safe”.
- hackermailman 9mo agoSometimes except I learned the hard way that if you write everyday Python math code it's actually variable-time arithmetic and totally unsuitable for applied cryptography, oops
- llmslave2 9mo agoOr perhaps because you are using an uncommon definition for "memory safety".
- codys 9mo agoOne 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)
- llmslave2 9mo agoHas this problem (which is really a race condition problem) ever been shown to be exploitable or lead to issues?
- codys 9mo agoIt 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.
- llmslave2 9mo agoThe definition from the posted website seems sufficient to me.
- codys 9mo agoIn that case, I can just refer back to my original comment: https://news.ycombinator.com/item?id=46388948 https://news.ycombinator.com/item?id=46388948 And then note that memorysafety.org says this (in case folks haven't read it): > Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used. They then provide an examine of out-of-bounds read/write. Which is the exact example I noted in my linked comment. (Note: memorysafety.org does not provide a concrete definition of memory safety, but we get enough from what it says in this case) The site does not require the known existence of an exploit in popular software (and does not require that _any_ exploit be possible, a bug is sufficient), merely that the language fails to block "certain types of bugs".
- woodruffw 9mo agoI 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.
- codys 9mo agoGo 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://research.swtch.com/gorace https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html?m=1 https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html
- aw1621107 9mo ago"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.
- codys 9mo agoInteresting 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.
- aw1621107 9mo agoI don't know if I'd agree that "probabilistically memory safe" is better because it also fits a hypothetical implementation which catches out-of-bounds accesses /etc. 50% of the time regardless of whether in-the-wild exploits exist. Maybe something like "Go is effectively/practically memory safe at the moment" would be better? Or if you want to put on your lawyer hat "Go is not known to be memory unsafe at this time", but that's rather cumbersome at best.
- fweimer 9mo agoI'm not involved in Go development, only watching from the sidelines. I think it's very likely due to the project dynamics that after the first (published) exploit against real software, the compiler will be changed so that low-level data races can no longer result in type confusion. There will be some overhead, but it's going to be quite modest. I think this is realistic because there's already a garbage collector. Indirection to fresh heap allocations can be used to make writes to multiple fields to appear as atomic. So I think Go is absolutely not in the same bucket as C, C++, or unsafe Rust.
- pjmlp 9mo agoBecause it is, from point of view of what memory corruption issues are there in C and C++. Waiting for the traditional Rust reply.
- rurban 9mo agoAnd they are also promoting rust as memory safe, whilst ignoring the true memory safe languages (the ones with a GC), which is kinda hilarious. Politicians