x/sys: invalid use of unsafe.Pointer in ioctl arg parameters

[brunnre8]

From the documentation of unsafe.Pointer:

(4) Conversion of a Pointer to a uintptr when calling syscall.Syscall.

The Syscall functions in package syscall pass their uintptr arguments directly to the operating system, which then may, depending on the details of the call, reinterpret some of them as pointers. That is, the system call implementation is implicitly converting certain arguments back from uintptr to pointer.

If a pointer argument must be converted to uintptr for use as an argument, that conversion must appear in the call expression itself

Now, as far as I can tell this forces packages to adhere to exactly that.

The code in x/sys clearly violates that rule.

in unix/ioctl.go there's

  // IoctlSetPointerInt performs an ioctl operation which sets an
  // integer value on fd, using the specified request number. The ioctl
  // argument is called with a pointer to the integer value, rather than
  // passing the integer value directly.
  func IoctlSetPointerInt(fd int, req uint, value int) error {
          v := int32(value)
          return ioctl(fd, req, uintptr(unsafe.Pointer(&v)))
  }

and the declaration of ioctl in zsyskall_linux.go:

  func ioctl(fd int, req uint, arg uintptr) (err error) {
          _, _, e1 := Syscall(SYS_IOCTL, uintptr(fd), uintptr(req), uintptr(arg))
          if e1 != 0 {
                  err = errnoErr(e1)
          }
          return
  }

I've asked on the mailing list if that's valid usage of unsafe, @ianlancetaylor wasn't sure and told me to open an issue here for further discussion. (https://groups.google.com/g/golang-nuts/c/Ocpy8CKs7ZI/m/3ym8gnuBFgAJ)

[cuonglm]

This is safe.

• v will be kept alive through ioctl call.
• The rule is only applied for pointer must be converted to uintptr, ioctl does uintptr(arg) where arg is an uintptr, not a pointer.

[cuonglm]

cc @mdempsky

[mdempsky]

I don't think that code is safe.

The ioctl function does not have any pragmas to mark it as a syscall function, so the compiler won't know to do anything special for it. So the call to ioctl could potentially grow the stack, and then the arg pointer would be stale pointing to old memory.

[cuonglm]

I don't think that code is safe.

The ioctl function does not have any pragmas to mark it as a syscall function, so the compiler won't know to do anything special for it. So the call to ioctl could potentially grow the stack, and then the arg pointer would be stale pointing to old memory.

Hmm, so, whether it violates unsafe pointer rule?

Maybe the right fix is passing in an unsafe.Pointer instead of an uintptr 🤔

[cuonglm]

Maybe the right fix is passing in an unsafe.Pointer instead of an uintptr 🤔

or using go:nosplit

[mdempsky]

Maybe the right fix is passing in an unsafe.Pointer instead of an uintptr

I think so. The Linux ioctl man page at least says that the third argument is always a pointer. (If there are any ioctls that do actually pass a scalar value directly instead of a pointer, they'll need a separate utility wrapper.)

[ianlancetaylor]

@mdlayher added IoctlSetInt for Linux in https://golang.org/cl/44009 for #20474. That suggests that Linux has some ioctls that don't take a pointer value for the third argument, although off hand I do not know what they are.

[lhl2617]

@mdlayher added IoctlSetInt for Linux in https://golang.org/cl/44009 for #20474. That suggests that Linux has some ioctls that don't take a pointer value for the third argument, although off hand I do not know what they are.

From https://man7.org/linux/man-pages/man2/ioctl.2.html:

The third argument is an untyped pointer to memory

From https://docs.oracle.com/cd/E23824_01/html/821-1463/ioctl-2.html

The arg argument represents a third argument that has additional information that is needed by this specific device to perform the requested function. The data type of arg depends upon the particular control request, but it is either an int or a pointer to a device-specific data structure.

It thus seems like IoctlSetInt was made for solaris consistent with the description in #20474. It should never be used for linux.

[lhl2617]

Relevant issue: https://github.com/golang/go/issues/34684

[gopherbot]

Change https://golang.org/cl/340915 mentions this issue: unix: generate ioctlNew on Linux with unsafe.Pointer arg

[bcmills]

@mdempsky, @ianlancetaylor, @mdlayher: was this fixed by CL 340915, or is there more to do here?

[mdlayher]

I believe the reason I didn't close this before was because I only fixed it for Linux. Similar changes would have to be made for *BSD and etc.

[thediveo]

@mdlayher added IoctlSetInt for Linux in https://golang.org/cl/44009 for #20474. That suggests that Linux has some ioctls that don't take a pointer value for the third argument, although off hand I do not know what they are.

Here we are, FICLONE https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html ... which I didn't knew existed a few moments ago 😁

[gopherbot]

Change https://go.dev/cl/469315 mentions this issue: unix: add ioctlPtr with unsafe.Pointer arg on other unices

[gopherbot]

Change https://go.dev/cl/469675 mentions this issue: syscall: avoid passing Go pointers as uintptr in exec tests

[gopherbot]

Change https://go.dev/cl/469835 mentions this issue: unix: add ptracePtr that accepts pointer arg as unsafe.Pointer

[gopherbot]

Change https://go.dev/cl/471119 mentions this issue: unix: add ioctlPtr with unsafe.Pointer arg on other unices (cont)

[bcmills]

@dmgk, can this issue be closed now, or is there more work remaining for it?

[dmgk]

I believe this is done, closing.

[brunnre8]

Thanks a lot to everyone involved