The slice is simply unsynchronized, so a user of the slice may pull out one array but a length that was for a different array.
https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
-9 karma · joined July 3, 2021
https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
What confuses me is that in 2010 all devs were finally on the "don't block stuff based on regex" train, and now all a sudden nothing matters just Cloudflare is God with some handwavy explanation of how they "did a risk analysis".
This explains it (tl;dr nobody bothers to formally define what errors they return, and the blindly propagate such unspecified errors, and it leads to ambiguity and unintentional program behavior)
https://www.lainchan.org/%CE%BB/src/1612397614615.jpg
People keep saying this but it happened 20 years ago. This reminds me of shit like the postal service requiring photo ID to receive a package and people complaining about NSA hundreds of years later. Now you need a phone to play a game and some of the most popular need literal photo ID checks. Imagine, sending your photo ID which if stolen people can steal your money, to a bunch of newgrads running a game studio. This is what people (kids and manchildren) accept to address the overstated problem of game cheating. I played thousands of hours of games for 20 years and the number of cheaters I ran into is around 10 or 20. Most players of games (including the ones who complain about "cheaters") do not even have a clue what a game cheat is. They think some guy has some cheat that only works in this weird scenario that happens 1/100 games. Yeah, can you guys stop making me need photo ID for to play some stupid game? This is no different than every obnoxious statist concern that gets addressed by some charlatan who purports to be saving the world by ruining everyone's day (almost any time I install or configure a game my day is ruined, imagine a typical dependency hell but 10x worse). And no, I haven't ran into little cheaters because of "sophisticated anticheat" (stuff like punkbuster is extremely incompetent), it's because public hacks simply get blacklisted once they become big enough to matter.
It's a the same as the problem of knowing what data is used in what thread, which is hard and unsolvable by automation, so I doubt it's an easy problem.
Dilettante programmers certainly do not know the following:
1. Go slices, strings, and interface values are unsafely non-atomic. It's documented on some obscure page (even the spec does not document it AFAIK, which is also broken).
2. What a data race is
Even if they know #1, they will still write code like: modifying a slice within a structure and setting a thread-shared pointer to point to that structure.
Again, most programmers are taught "things need locks, for reasons". At best, they will pointlessly lock things, then another programmer will come "debunk" them and remove the lock because "the thing being locked is atomic". Note how none of this involves any thought of the memory model. That's because they do not know it exists.
As for people who know #2, yes that is enough to avoid memory corruption without needing to know #1, however, they are not sufficiently informed how much data races matter (as executing shellcode is not an expected outcome of writes to your data being non observable).
Any consequence is _not_ fair game. "Memory Models" only involve stuff like tossing out sequential consistency [1]. They never say or imply something like "if you have a data race, anything can happen [including executing code on the stack]". Go slices exposing implementation details in a way that makes the language memory-unsafe is a completely different issue. If Go was sequentially consistent (so it had no "Memory Model" to violate), it would still not make the language memory-safe, because it would still write the array pointer and be pre-empted before writing the length.
> And that's not interesting
It matters because all programs have bugs (apparently), and so we'd like them to fail in a less harmful way than executing shellcode submitted by a client.
> it's easy to spot and fix data races, and Go provides plenty of tooling for that purpose.
Never used the data race detector but it probably can only identify low hanging fruit, and is not a substitute for the developer education problem.
Okay I think I see your confusion: You can actually avoid slices causing buffer overflows because the language requires you to have a happens-before relationship for all data shared across threads in the first place. That is, even if you share a boolean or across threads, you would be sure to establish a happens-before relationship if you are in the know. However, this does not rebuke my original argument, which assumes that most devs are not in the know. They do not know about slices being unsafe, nor do they know about happens-before. So they are not educated to prevent this mistake. Also, avoiding data races is hard.
and?
> so whatever it accomplishes is irrelevant.
I have no idea what point you are making. _Of course_ there has to be a bug in the code for there to be a buffer overflow vuln. Or are you objecting that they put contrived code to make the race work better (this is the concept of a PoC)? None of the patterns in that code are unlikely in practice.
The "Exploiting the slice type" section.
This is true, but they do not know that. If you do not give some kind of substantiation, they will shrug it off and go back to "nah this thing doesn't need a mutex", like with a polling variable (contrived example).
Actually, most practitioner code has bugs from their implicit assumptions that shared variable writes are visible or ordered the way they think they are.
The common programmer does not understand that you've just transformed their program - for which they were taught merely that multiple threads needs synchronization - into a new game, which has an entire separate specification, where every shared variable obeys a set of abstruse rules revolving around the happens-before relationship. Locks, mutexes, atomic variables are all one thing. Fences are a completely different thing. At least in the way most people intuit programs to work.
Go tries to appeal to programmers as consumers (that is, when given a choice between cleaner design and pleasing the user who just wants to "get stuff done", they choose the latter), but yet also adds in traditional complexities like this. Yes, there is performance trade off to having shared memory behave intuitively, but that's much better than bugs that 99% of your CHOSEN userbase do not know how to avoid. Also remember Go has lots of weird edge cases, like sharing a slice across threads can lead to memory corruption (in the C / assembly sense, not merely within that array) despite the rest of the language being memory-safe. Multiply that by the "memory model".
Edit: forgot spaces between paragraphs.