4 ms·

This is only true if you can prove that data races will never cause any bounds checks to be wrong. The blog post linked upthread suggests otherwise, and even ap

This is only true if you can prove that data races will never cause any bounds checks to be wrong. The blog post linked upthread suggests otherwise, and even appears to provide a counter-example to your claim.

pjmlp 9y ago
As mentioned in that blog post > You'll notice my address() trick to get the address of a function or variable that I used in my previous exploit. We're relying on package fmt and its %p format specifier which is implemented by using the unsafe package, so we don't need to use it ourselves.
- millstone 9y ago
  unsafe code is not required or used. The exploit constructs a confused interface value, whose vtable refers to a different type than is what is stored. The result is that Go treats an integer as a function and jumps to it. The unsafe address() is used to get the address of a function to store in the int, to demonstrate the potential for shellcode injection. But you could just as easily assign pp := 12345 and produce a SIGSEGV or SIGILL, which would not be possible if Go were memory safe.
  - deleted 9y ago
    [deleted]
  - pjmlp 9y ago
    On the contrary, if Go was unsafe that would just corrupt memory and the program would just carry on without anyone noticing the memory was corrupted until it was too late, in another completely different stack. The exploit was only possible thanks to using the unsafe package, even if indirectly. It is exactly because Go is memory safe that a SIGSEGV or SIGILL is produced the exact moment the memory gets corrupted and not 2 hours later in a complete different stack trace.
- burntsushi 9y ago
  So? The code they wrote doesn't use `unsafe`. So presumably, you need to modify your claim to this then I guess? > A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses, or if you've used something that exposes details that only the unsafe package exposes, such as fmt's %p specifier. I mean, you are like, the ultimate pedant, so I figured you'd uniquely appreciate this. You can't just say, "use unsafe or anything that uses unsafe," because it's turtles all the way down. You've got to draw that line somewhere. If the %p specifier really is required for an exploit and there's nothing else that exposes that (sans unsafe), then that's great news! But is that the whole story?

pjmlp 9y ago

As mentioned in that blog post > You'll notice my address() trick to get the address of a function or variable that I used in my previous exploit. We're relying on package fmt and its %p format specifier which is implemented by using the unsafe package, so we don't need to use it ourselves.

millstone 9y ago
unsafe code is not required or used. The exploit constructs a confused interface value, whose vtable refers to a different type than is what is stored. The result is that Go treats an integer as a function and jumps to it. The unsafe address() is used to get the address of a function to store in the int, to demonstrate the potential for shellcode injection. But you could just as easily assign pp := 12345 and produce a SIGSEGV or SIGILL, which would not be possible if Go were memory safe.
- deleted 9y ago
  [deleted]
- pjmlp 9y ago
  On the contrary, if Go was unsafe that would just corrupt memory and the program would just carry on without anyone noticing the memory was corrupted until it was too late, in another completely different stack. The exploit was only possible thanks to using the unsafe package, even if indirectly. It is exactly because Go is memory safe that a SIGSEGV or SIGILL is produced the exact moment the memory gets corrupted and not 2 hours later in a complete different stack trace.
burntsushi 9y ago
So? The code they wrote doesn't use `unsafe`. So presumably, you need to modify your claim to this then I guess? > A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses, or if you've used something that exposes details that only the unsafe package exposes, such as fmt's %p specifier. I mean, you are like, the ultimate pedant, so I figured you'd uniquely appreciate this. You can't just say, "use unsafe or anything that uses unsafe," because it's turtles all the way down. You've got to draw that line somewhere. If the %p specifier really is required for an exploit and there's nothing else that exposes that (sans unsafe), then that's great news! But is that the whole story?