News for hackers. Stuff that matters.

A comment on Updating the Go Memory Model. Parent comment

Re:Updating the Go Memory Model by gpderetta on Monday July 12, 2021 @03:37PM (#27814112)
It is better than invoking random code because the runtime mistakes some data for a vtable pointer.
[ Parent | on HN ]
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.
[ Parent | on HN ]
Re:Updating the Go Memory Model by yc12340 on Monday July 12, 2021 @11:47PM (#27817459)
...and easy to exploit
[ Parent | on HN ]
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.

[ Parent | on HN ]
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.

[ Parent | on HN ]