News for hackers. Stuff that matters.
Re:Updating the Go Memory Model by ngrilly on Monday July 12, 2021 @03:59PM (#27814374)
I agree that a data race on an interface value in Go, is worse than an infinite loop or a memory leak, because it can lead to calling the wrong method on a value, which is hard to debug.
Re:Updating the Go Memory Model by yc12340 on Monday July 12, 2021 @11:47PM (#27817459)
...and easy to exploit
Re:Updating the Go Memory Model by ngrilly on Tuesday July 13, 2021 @11:42AM (#27822343)
Not easy, but definitely possible:

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

> We have to admit that exploiting this requires a fairly specific situation in which there is a data race we could trigger and some structs with function pointers around.

Re:Updating the Go Memory Model by gpderetta on Wednesday July 14, 2021 @05:27AM (#27831176)
Nice.

I would note that Java is designed to run untrusted code, so fat pointers would be unacceptable as the attacker could easily craft the code required to trigger the race. Go does not claim to provide sandboxing of untrusted programs.