2 ms·

Another canard, unfortunately. "Segfault" is simply Go's reporting convention for things like nil pointer hits. "Segfaults" are not, in fact, part of the defini

by tptacek 11mo ago

Another canard, unfortunately. "Segfault" is simply Go's reporting convention for things like nil pointer hits. "Segfaults" are not, in fact, part of the definition for memory safety or a threshold condition for it. All due respect to Ralf's Ramblings, but I'm going to rest my case with the Prossimo page on memorysafety.org that I just posted. This isn't a real debate.

vlovich123 11mo ago
> Segfault" is simply Go's reporting convention for things like nil pointer hits. Blatantly false. From Ralf’s post: > panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863] The panic address is 42, a value being mutated, not a nil pointer. You could easily imagine this address pointing to a legal but unintended memory address resulting in a read or write of unintended memory.
- tptacek 11mo ago
  No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth. https://go.dev/play/p/0fUzmP0cLEa https://go.dev/play/p/0fUzmP0cLEa
  - vlovich123 11mo ago
    You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example. > When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes. If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation.
    - tptacek 11mo ago
      Please do explain the exploit gadget you're talking about.
  - josefx 11mo ago
    > That looks like a struct offset dereference from a nil pointer, for what it's worth. The 42 is an explicit value in the example code. From what I understand the code repeatedly changes the value assigned to an interface variable from an object containing a pointer to an object containing an integer. Since interface variables store the type of the assigned value, but do not update both type and value atomically a different thread can interpret whatever integer you put into it as a valid pointer. Putting a large enough value into the integer should avoid the protected memory page around 0 and allow for some old fashioned memory corruption.

by tptacek 11mo ago

vlovich123 11mo ago

> Segfault" is simply Go's reporting convention for things like nil pointer hits. Blatantly false. From Ralf’s post: > panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863] The panic address is 42, a value being mutated, not a nil pointer. You could easily imagine this address pointing to a legal but unintended memory address resulting in a read or write of unintended memory.

tptacek 11mo ago
No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth. https://go.dev/play/p/0fUzmP0cLEa https://go.dev/play/p/0fUzmP0cLEa
- vlovich123 11mo ago
  You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example. > When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes. If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation.
  - tptacek 11mo ago
    Please do explain the exploit gadget you're talking about.
- josefx 11mo ago
  > That looks like a struct offset dereference from a nil pointer, for what it's worth. The 42 is an explicit value in the example code. From what I understand the code repeatedly changes the value assigned to an interface variable from an object containing a pointer to an object containing an integer. Since interface variables store the type of the assigned value, but do not update both type and value atomically a different thread can interpret whatever integer you put into it as a valid pointer. Putting a large enough value into the integer should avoid the protected memory page around 0 and allow for some old fashioned memory corruption.