proposal: add GOEXPERIMENT=checkptr

[amscanne]

This is a proposal for this change, and see if there's any interest in having it move forward.

Background

During stack growth, pointers that have values between 0 and minLegalPointer will cause a "invalid pointer found on stack" exception to be thrown by the runtime. This suggests that storing these pointers on the stack is not a valid operation, i.e. the following code may cause a runtime exception if the stack happens to grow.

p := unsafe.Pointer(uintptr(1))

Since this is not a permitted state and will cause a runtime exception, it is preferable for the user to receive a recoverable error at the time the state is introduced. Even if this results in the program crashing, the full stack trace will be available making the cause of the problem much easier to diagnose.

Proposal

I propose to add code that causes a recoverable panic at the time the conversion is made. This conversion adds a small cost to each unsafe.Pointer cast. I believe that these conversions in user code should be relatively rare (usually associated with some other costly event, such as allocating a new object), but there may be cases where it's common (e.g. some CGo usage?). The original change did not apply these checks to code in the runtime package itself, due to its presumed safety and the fact that the conversions were common for the implementation of core types (e.g. map, channels, etc.).

Alternate Proposal

As noted in the original change, this behavior may be surprising. Users may be encoding some CGo void* equivalents as pointers in Go, which could contain "illegal" values. The constraint imposed by the stack growth code is non-obvious and undocumented.

Currently, debug.invalidptr is used in both heapBitsForObject and stack adjustment and defaults to on. I propose that a new debug variable is introduced, debug.stackptr, that toggles the behavior of the check during stack growth. I would advocate that this check should default to off, but regardless it would allow just that check to be disabled if it proves problematic.

[cznic]

I believe that these conversions in user code should be relatively rare (usually associated with some other costly event, such as allocating a new object), but there may be cases where it's common (e.g. some CGo usage?).

Virtual machines are perhaps rare, but they may use code making such conversions every few nanoseconds and in that case the performance would be hurt substantially.

[bcmills]

the following code may cause a runtime exception if the stack happens to grow.

The example you give is one that could be caught at compile-time (e.g. by vet). Do you have more realistic examples to demonstrate the problem?

[bcmills]

Users may be encoding some CGo void* equivalents as pointers in Go, which could contain "illegal" values.

Note that in C, converting an arbitrary integer to void* produces “implementation-defined” behavior. Portable C code cannot convert arbitrary integers to void*, just as portable Go code cannot convert arbitrary integers to unsafe.Pointer.

[cznic]

Portable C code cannot convert arbitrary integers to void*, ...

True, yet unfortunately some well known and widely used C code bases do that (and not only to void*). For example SQLite, including magic-valued function pointers, IIRC.

[bcmills]

See also #19928, #21897, and #21730.

[amscanne]

Virtual machines are perhaps rare, but they may use code making such conversions every few nanoseconds and in that case the performance would be hurt substantially.

I assume you're talking about language-level virtual machines here, where the implementation is in Go. Why would they require constant conversions between uintptr and unsafe.Pointer? I don't follow. It seems like their internal implementations would aim to be well-typed, just like everything else. Do you have an example?

The example you give is one that could be caught at compile-time (e.g. by vet). Do you have more realistic examples to demonstrate the problem?

Sure. Suppose you have something like:

   // C.create_foo => unsafe.Pointer(), maybe encoding errors as well
   foo := create_foo()
   // ... runtime can die starting here.
   if is_foo_okay(foo) {
      ...
   }

You might argue that the create_foo() interface is bad. Agreed, but it's still common. It's even used within the runtime itself for e.g. mmap return values within mem_linux.go:

func sysAlloc(n uintptr, sysStat *uint64) unsafe.Pointer {
  	p := mmap(nil, n, _PROT_READ|_PROT_WRITE, _MAP_ANON|_MAP_PRIVATE, -1, 0)
  	if uintptr(p) < 4096 {
  		if uintptr(p) == _EACCES {
  			print("runtime: mmap: access denied\n")
  			exit(2)
  		}
  		if uintptr(p) == _EAGAIN {
  			print("runtime: mmap: too much locked memory (check 'ulimit -l').\n")
  			exit(2)
  		}
  		return nil
  	}
  	mSysStatInc(sysStat, n)
  	return p
  }

The above function uses "invalid" behavior per #21897. If it were not marked with go:nosplit, and happened to grow while p was on the stack, then it would panic the runtime.

I also encountered this issue in a specific context as well that I will follow up with you about separately.

Note that in C, converting an arbitrary integer to void* produces “implementation-defined” behavior. Portable C code cannot convert arbitrary integers to void*, just as portable Go code cannot convert arbitrary integers to unsafe.Pointer.

I'm with you here, but it still happens. The go runtime itself is guilty of this.

[bcmills]

You might argue that the create_foo() interface is bad. Agreed, but it's still common.

Isn't that exactly the use-case that the Go uintptr type (and the corresponding C99 uintptr_t type) is meant to address? (Why return void* / unsafe.Pointer when the caller can always do that conversion explicitly once they have verified that the value is, in fact, a valid pointer?)

It's even used within the runtime itself

The runtime can rely upon whatever implementation details it likes. (Runtime code is not user code!)

That said, arguably we should fix runtime.mmap to return a uintptr so that it sets a better example.

[cznic]

@amscanne

I assume you're talking about language-level virtual machines here, where the implementation is in Go.

I'm talking about a particular VM.

Why would they require constant conversions between uintptr and unsafe.Pointer?

VM memory consists of the code memory, stack, text and data segments and heap memroy. Except for the code memory, all other VM memory is allocated outside of the Go runtime using mmaps. VM pointers are uintptrs. Every access to any non code memory converts a particular uintptr to an unsafe.Pointer. Essentially every VM operation/instruction has two or more mmaped memory accesses, for example AddI32.

[amscanne]

Isn't that exactly the use-case that the Go uintptr type (and the corresponding C99 uintptr_t type) is meant to address? (Why return void* / unsafe.Pointer when the caller can always do that conversion explicitly once they have verified that the value is, in fact, a valid pointer?)

Sure, but this doesn't always happen. See the runtime. Note that in the reference change, I update the code there to use the uintptr correctly:
https://go-review.googlesource.com/c/go/+/34719/1/src/runtime/mem_linux.go

The runtime can rely upon whatever implementation details it likes. (Runtime code is not user code!)

Uff. The argument that the runtime doesn't need to be "valid" Go code is disconcerting. (I say this because one of the referenced issues was closed as not a valid thing to do.) I understand the need for the pragmatic considerations and exceptions for the runtime (hence the exception in the original change), but that's a different thing.

I'm talking about a particular VM.

Gotcha. Yes, I see the calls you're referring to here:
https://github.com/cznic/virtual/blob/06a14e3fe719b20921b8be3ff81847eac0e53527/cpu.go#L65

This does hit the crux of the issue. The code there could be slightly restructured and there would be the risk of triggering runtime errors. (If the pointers lived on the stack during a growth event instead of being immediately consumed.)

I'm not really sure about the cost in that case anyways. The branch predictor will likely make most of it disappear. If the proposal is friendly (though I get the sense that it is not), I would happily run some benchmark if you're got it to assess the impact for your case.

[bcmills]

Note that in the reference change, I update the code there to use the uintptr correctly

That seems like a good idea regardless of whether we also add the proposed dynamic check.

[bcmills]

I note the following in the reference change description:

This will only happen on conversion to unsafe.Pointer from
non-pointer types, so most internal runtime pointer mangling should be
free from these checks.

Does that actually address a significant fraction of bad pointers? If the pointer is coming from C code, odds are good that it's already encoded as an unsafe.Pointer.

Or does the code generated by cgo itself do explicit conversions? (If so, it still seems unfortunate to couple the runtime pointer-validity check to a cgo implementation detail, especially when the interaction between cgo and the compiler is in question: see #16623.)

[amscanne]

Does that actually address a significant fraction of bad pointers? If the pointer is coming from C code, odds are good that it's already encoded as an unsafe.Pointer.

Or does the code generated by cgo itself do explicit conversions? (If so, it still seems unfortunate to couple the runtime pointer-validity check to a cgo implementation detail, especially when the interaction between cgo and the compiler is in question: see #16623.)

This is a good question. It does seem like the structure would currently avoid this check. (The generated code effectively passes a *unsafe.Pointer which is filled in by the generated C stub.) I think the logical thing to do would be to update the CGo code generation to use uintptr across the boundary and convert to unsafe.Pointer only on the Go side.

[gopherbot]

Change https://golang.org/cl/71270 mentions this issue: runtime: separate error result for mmap