x/sys/unix: access to ELF auxiliary vector

[ghost]

Proposal Details

like os.Args and os.Environ, I was wondering why there is neither an API to get ELF auxiliary vector nor Aux type. C does provide them in Elf.h

[ianlancetaylor]

If we do this I think it should be in the golang.org/x/sys/unix package. The os package is mainly aimed at OS-independent functionality, but auxv is specific to ELF-based systems.

[ghost]

so, in the current state of art, is there no way to get the full aux vector?

[ianlancetaylor]

As far as I know there is not.

[adonovan]

so, in the current state of art, is there no way to get the full aux vector?

Not from Go. In C you can usually derive it from the address of the environ symbol, but it may be non-portable.

[seankhliao]

I see runtime has an internal sysauxv which x/sys/cpu hooks into, falling back to /proc/self/auxv. Is the proc file sufficient?

[ghost]

/proc/self/auxv

could you provide a minimal example on how to retrieve auxv values?

[seankhliao]

see https://go.googlesource.com/sys/+/9a28524796a519b225fedd6aaaf4b1bf6c06c002/cpu/hwcap_linux.go#26

[florianl]

#68089 advocated to expose runtime.getAuxv() and make it a public API. Exposing the auxiliary vector via os was not considered as a viable option, as os should be more of a higher level layer with cross OS compatability.
But adding a public API, like runtime.Getauxv(), would also introduce some kind of OS specifics into runtime.

An alternative, also mentioned in #67839 (comment) and go.dev/cl/458256, could be an exposure of the auxiliary vector via golang.org/x/sys. golang.org/x/sys is OS specific and therefore a perfect fit. The unknown for me in this approach is how golang.org/x/sys can get access to something, that only runtime knows about, without techniques like //go:linkname.

[ianlancetaylor]

golang.org/x/sys/cpu already reaches into the runtime to fetch the auxiliary vector, using go:linkname. Adding an exported function in golang.org/x/sys/unix isn't going to make matters better or worse.

Reaching in from packages in x/sys is better than reaching in from arbitrary external packages, because we can change the x/sys packages ourselves, and then drop the support in runtime when we no longer support older versions of the x/sys packages.

[florianl]

Thanks for the clarification. I really wasn't sure about x/sys, as I considered x/sys as an external package, "just" in a more controlled manner.

If it helps, I can open a CL against x/sys for GetAuxv() []uintptr using go:linkname.

[ianlancetaylor]

Thanks, may as well wait for the proposal process.

[lmb]

Is the proc file sufficient?

/proc is tricky because it has additional permission checks and interacts with capabilities. See https://dxuuu.xyz/filecaps.html. Using auxv from the runtime really is a lot less error prone.

[florianl]

Is there something I can help with to get feedback on this proposal or continue with the proposal process?

[rsc]

We should drop the "Get" but func Auxv() []uintptr in x/sys/unix seems fine?

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[aclements]

We should drop the "Get" but func Auxv() []uintptr in x/sys/unix seems fine?

Auxv is a sequence of key/value pairs, so I'd lean toward a slightly more structured API: func Auxv() [][2]uintptr

[aclements]

There should probably be an error result as well, since there are corner cases where we just can't get the auxv (e.g., in c-shared mode on Android where /proc/self/auxv is unreadable).

[aclements]

Have all remaining concerns about this proposal been addressed?

The proposal is to add the following to golang.org/x/sys/unix:

// Auxv returns the ELF auxiliary vector as a sequence of key/value pairs.
// The returned slice is always a fresh copy, owned by the caller.
// It returns an error on non-ELF platforms, of if the auxiliary vector cannot be accessed,
// which happens in some locked-down environments and build modes.
func Auxv() ([][2]uintptr, error)

[aclements]

Based on the discussion above, this proposal seems like a likely accept.

The proposal is to add the following to golang.org/x/sys/unix:

// Auxv returns the ELF auxiliary vector as a sequence of key/value pairs.
// The returned slice is always a fresh copy, owned by the caller.
// It returns an error on non-ELF platforms, of if the auxiliary vector cannot be accessed,
// which happens in some locked-down environments and build modes.
func Auxv() ([][2]uintptr, error)

[aclements]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— aclements for the proposal review group

The proposal is to add the following to golang.org/x/sys/unix:

// Auxv returns the ELF auxiliary vector as a sequence of key/value pairs.
// The returned slice is always a fresh copy, owned by the caller.
// It returns an error on non-ELF platforms, of if the auxiliary vector cannot be accessed,
// which happens in some locked-down environments and build modes.
func Auxv() ([][2]uintptr, error)

[seehuhn]

of if the auxiliary vector cannot be accessed

s/of if/or if/

[gopherbot]

Change https://go.dev/cl/644295 mentions this issue: unix: add Auxv()

[gopherbot]

Change https://go.dev/cl/646535 mentions this issue: runtime: adjust comments for auxv getAuxv