| ▲ | vlovich123 11 hours ago |
| I’m not aware of any definition of memory safety that allows for segfaults- by definition those are an indication of not being memory safe. It is true that go is only memory unsafe in a specific scenario, but such things aren’t possible in true memory safe languages like c# or Java. That it only occurs in multithreaded scenarios matters little especially since concurrency is a huge selling point of the language and baked in. Java can have data races, but those data races cannot be directly exploited into memory safety issues like you can with Go. I’m tired of Go fans treating memory safety as some continuum just because there are many specific classes of how memory safety can be violated and Go protecting against most is somehow the same as protecting against all (which is what being a memory safe language means whether you like it or not). I’m not aware of any other major language claiming memory safety that is susceptible to segfaults. https://www.ralfj.de/blog/2025/07/24/memory-safety.html |
|
| ▲ | tptacek 10 hours ago | parent | next [-] |
| Another canard, unfortunately. "Segfault" is simply Go's reporting convention for things like nil pointer hits. "Segfaults" are not, in fact, part of the definition for memory safety or a threshold condition for it. All due respect to Ralf's Ramblings, but I'm going to rest my case with the Prossimo page on memorysafety.org that I just posted. This isn't a real debate. |
| |
| ▲ | vlovich123 9 hours ago | parent [-] | | > Segfault" is simply Go's reporting convention for things like nil pointer hits. Blatantly false. From Ralf’s post: > panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863] The panic address is 42, a value being mutated, not a nil pointer. You could easily imagine this address pointing to a legal but unintended memory address resulting in a read or write of unintended memory. | | |
| ▲ | tptacek 9 hours ago | parent [-] | | No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth. https://go.dev/play/p/0fUzmP0cLEa | | |
| ▲ | vlovich123 7 hours ago | parent [-] | | You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example. > When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes. If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation. | | |
|
|
|
|
| ▲ | afdbcreid 9 hours ago | parent | prev [-] |
| Rust is susceptible to segfaults when overflowing the stack. Is Rust not memory safe then? Of course, Go allows more than that, with data races it's possible to reach use after free or other kinds of memory unsafety, but just segfaults don't mark a language memory unsafe. |
| |
| ▲ | cyberax 9 hours ago | parent [-] | | Go is most emphatically NOT memory-safe. It's trivially easy to corrupt memory in Go when using gorotuines. You don't even have to try hard. This stems from the fact that Go uses fat pointers for interfaces, so they can't be atomically assigned. Built-in maps and slices are also not corruption-safe. In contrast, Java does provide this guarantee. You can mutate structures across threads, and you will NOT get data corruption. It can result in null pointer exceptions, infinite loops, but not in corruption. | | |
| ▲ | tptacek 9 hours ago | parent [-] | | This is just wrong. Not that you can't blow up from a data race; you certainly can. Simply that any of these properties admit to exploitable vulnerabilities, which is the point of the term as it is used today. When you expand the definition the way you are here, you impair the utility of the term. Serious systems built in memory-unsafe languages yield continual streams of exploitable vulnerabilities; that remains true even when those systems are maintained by the best-resourced security teams in the world. Functionally no Go projects have this property. The empirics are hard to get around. | | |
| ▲ | cyberax 6 hours ago | parent [-] | | There were CVEs caused by concurrent map access. Definitely denials of service, and I'm pretty sure it can be used for exploitation. > Serious systems built in memory-unsafe languages yield continual streams of exploitable vulnerabilities I'm not saying that Go is as unsafe as C. But it definitely is NOT completely safe. I've seen memory corruptions from improper data sync in my own code. | | |
|
|
|
