Comment by monocasa
5 hours ago
The exploits aren't the only issue; they just get a lot of air time.
It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
They aren't the only issue in programming language theory, but they are the only issue in the ordinary context in which we discuss "memory safety", such that if someone not in a PLT forum says "is Go memory-safe" and you say "no" you will look a little batty.
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
No, it has real world implications. I worked at a heavy go shop; every time we'd have a new batch of hiring, the segfault bugs would start rolling in from these memory unsafety issues. The data race detector was good, but not perfect. Yes, those new devs would look at you batty until they saw the bug reports roll in.
And yeah, we tend to use the PLT definitions when we're talking about literal semantics of programming languages. Nothing in this thread mandates a security focused sub-definition.
And even Rob Pike described Go as "not purely memory safe", in a slide that obviously references this exact data race behavior. https://go.dev/talks/2012/splash.slide#49 They considered this a practical tradeoff for simplicity versus the major managed languages defining what happens during data races in a way that doesn't allow you to break memory safety.
Again: I am not disputing that there are correctness issues that come from having Go's concurrency and memory model, just like there are in (the large majority of) other languages with similar models. But those issues are not security problems, and security is what we're talking about when we talk about memory safety.
1 reply →