The issue here is that the language could have been designed to avoid such problems. Interfaces could have been double-boxed and slices could have been (ptr, start, end) with start/end untrusted by the implementation.
-
-
How much more complicated and slow would the language need to be to address the threat model of untrusted code being compiled inside a trusted unit? Also, why do you mention slices? Go has slices implemented as {ptr, len, cap} and performs boundary checks.
-
It doesn’t need to be complicated and slow at all. Java and C# designed interfaces without those problems (much earlier than Go did). The problem with slices is that Go trusts the length. So a race could overwrite ptr to point to a smaller alloc, allowing for OOB R/W.
- 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.