On Thu, May 16, 2019 at 5:24 AM Matt Layher <mdlay...@gmail.com> wrote: > > I'm working on a project that involves an ioctl API on OpenBSD. The idea is > that you store a memory address in a union within another structure, and then > invoke the ioctl. When it returns, both the structure itself and the memory > pointed at by the address in the union are filled with data by the kernel. > > I originally wrote a pure Go version of this code that seems to work, but > after a conversation in #darkarts on Gophers Slack (starting at > https://gophers.slack.com/archives/C1C1YSQBT/p1557956939402700), several of > us were unsure if this version was actually safe. See the body of this > function: > > https://github.com/WireGuard/wgctrl-go/blob/7e04c64d5b80f1991b52c6025d6f59e6aa3a3939/internal/wgopenbsd/client_openbsd.go#L59 > > The concern was as follows: > > > i think the usage of `ifgrs` is unsafe... > > maybe it's alright because it'll always be heap allocated due to the > > dynamic size of it, but afaict, the compiler could deduce that it doesn't > > escape and then the call to ioctl could move it during a stack realloc.. > > After thinking it over and having a further discussion, I decided to try > passing a pointer to memory allocated with C.malloc instead, and this also > seems to work. > > https://github.com/WireGuard/wgctrl-go/pull/49/commits/05d446d3d7b2e376424e57a5167205a325d61781 > > My question is: is this necessary, and if so, have I implemented it > correctly? I've typically just passed pointers to structures with no other > pointers directly with Linux APIs; never a pointer to a structure that also > contains other pointers to other memory. I'm a little shaky on Cgo since I've > mostly gotten by without it during my time writing Go.
Pointers passed to unix.Syscall or syscall.Syscall are always safe. They will be treated as live for the duration of the call to Syscall, and they will not be moved. This is a special exception for functions written in assembly, documented at https://golang.org/pkg/unsafe/#Pointer. I don't see any obvious problem with your code. Note that things would be different if you were using cgo, which follows different and more complicated rules. But at least in this example, you aren't. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVpgLt4xx98vsq%3DxcjxHGb8aUTNZ6L_4iMnxZjZJYyvrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
