atomic128 9 days ago

This comes from a webpage where the challenge is to compromise the site, despite the fact that Go imports are disallowed (including unsafe). It's a puzzle game.

To clarify, I think Go is magnificent and I use it for everything. The racer() code is just a curiosity.

  • tptacek 9 days ago

    Right, it's a cool trick. It's just not material to real threat models, which is what people imply when they say "Go isn't memory safe".

    • tialaramex 9 days ago

      The fact Go has UB under data races has practical implications for sufficiently complex concurrent software. If you can induce a race on a non-trivial object, that's UB instantly - you can probably blow up the Go runtime and all bets are off.

      I would not characterise this fact, which is a design choice in Go, as similar to say a Rust soundness bug, which will sooner or later just get fixed. They aren't going to somehow magically fix this problem in Go, it's part of the design.

      • adonovan 9 days ago

        > They aren't going to somehow magically fix this problem in Go, it's part of the design.

        I wouldn't be entirely pessimistic.

        Russ's post https://research.swtch.com/gorace mentions a conservative representation for Go's data structures (essentially: more indirection) that would make it possible to implement them in a way that was robust to races, at an obvious large performance cost.

        More recently others have been investigating the possibility of using 128-bit atomic writes (on ARM and x86) to reduce the cost. Go's strings and interfaces are both 2-word structures. Slices are three words but by changing the field order atomicity can be achieved with 2-word writes. Of course it would break a lot of code that assumes the representation or the ABI.

      • tptacek 9 days ago

        My point has nothing to do with whether the language will achieve "soundness". It's that this is behavior that has not over the last 15 years produced exploitable vulnerabilities, despite extremely high incentives for those vulnerabilities to be unearthed.

      • arp242 9 days ago

        I think these are "if a tree falls in a forest and no one is around to hear it, does it make a sound?"-type musings.

        Whatever the case, it doesn't really affect anyone and it doesn't really matter.

    • Yoric 9 days ago

      Well, time will tell. As Go usage increases, it becomes a more tempting target, which means that more malicious third-parties will start poring over the code of the std library and the frameworks looking exactly for this kind of vulnerability.

      The same goes for Rust, Swift or Zig, of course.

    • kaba0 9 days ago

      How is it not material? You only need to accidentally write and read a map at the same time in language that is supposedly for concurrency (which is why not the same as parallelism, in its case it does largely correlate).

      This is a ridiculous design issue with big ramifications.